Вопросы Теги

закодируйте URL wihthin URL - апачский ультрасовременный прокси (ProxyPass)

Мне настроили ProxyPass для достижения следующего: На моем сервере я запускаю сервис, который обеспечивает API отдыха, слушающий на порте 7777. От стороны клиента я хочу смочь назвать этот API как это: http://example.org/servicename/PARAMETER

Полный вызов к этому API должен быть похожим на это: HTTP, ПОМЕЩЕННЫЙ http://example.org/servicename/PARAMETER (где PARAMETER некоторая строка). Внутренне это должно перевести в следующий URL: http://server.ip:7777/servicename/PARAMETER

Все работает как ожидалось, пока ПАРАМЕТР не как это: http://parameter.org (на самом деле я должен к URL закодировать его: http%3A%2F%2Fparameter.org). Так, в целом, вызов http://example.org/servicename/http%3A%2F%2Fparameter.org

http:// в параметре путает апачское продвижение к следующему сообщению об ошибке в ответ на вызов: 

!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>

Если я заменяю http%3A%2F%2Fparameter.org с, например, test, все работает, как это должно. Так или иначе http:// в параметре смущает апача. Существует ли способ позволить апачу проигнорировать его?

Моя текущая конфигурация этого vhost похожа на это:

<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>

Предпосылки:

  • Я не могу изменить поведение API. это - третье лицо.
  • Я должен смочь обеспечить URL как параметры.

Редактирование 1:

tail -f /var/log/apache2/example_access.log урожаи

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"
3
задан 20 August 2015 в 15:08
2 ответа

В конфигурации Apache по умолчанию для директивы AllowEncodedSlashes установлено значение off . Это означает, что: " ... Директива AllowEncodedSlashes разрешает использование URL-адресов, содержащих закодированные разделители путей [...] в информации о пути. При значении по умолчанию Off, такие URL-адреса отклоняются с помощью 404 (Not found) error . ... "

Таким образом, проблема в том, что mod_proxy не проксирует ваши POST-запросы на основе URL-адресов, поскольку Apache их отклоняет (с 404) до того, как mod_proxy предпримет действия.

Другая возможная проблема связана с процессом кодирования URL: ваш apache (интерфейс) обязательно получит правильно закодированную строку URL (ту, которую вы ему отправляете: http://example.org /servicename/http%3A%2F%2Fparameter.org ), и я ожидаю, что он (apache) будет декодировать его URL-адрес во время внутренней обработки связанного запроса POST. Поэтому я ожидаю, что mod_proxy внутри Apache получит реальный URL-адрес (не закодированный), и мне интересно, будет ли он во время проксирования выполнять цикл с кодировкой URL. В официальной документации ProxyPass я вижу: « Обычно mod_proxy канонизирует URL-адреса ProxyPassed. Но это может быть несовместимо с некоторыми серверными модулями, особенно теми, которые используют PATH_INFO. Дополнительное ключевое слово nocanon подавляет это и передает "необработанный" URL-путь на серверную часть. Обратите внимание, что это ключевое слово может повлиять на безопасность вашей серверной части, поскольку оно снимает обычную ограниченную защиту от атак на основе URL-адресов, обеспечиваемую прокси-сервером ", поэтому вам следует также оценить использование опции «nocanon».

Обе проблемы ( AllowEncodedSlashes и nocanon ) были упомянуты в этом вопросе StackOverflow

8
ответ дан 3 December 2019 в 05:03

Я думаю, что это имеет такое поведение, потому что в http: // / по-прежнему рассматривается как разделитель каталогов. Таким образом, вы ищете ресурс paramater.org в папке http: (под папкой, я не имею в виду настоящую папку, поскольку это может быть просто путь доступа, но вы может понять суть).

Я не думаю, что вы можете просто ввести / для ресурса в URL-адресе, поэтому вам нужно использовать% 2F

0
ответ дан 3 December 2019 в 05:03

Теги

Похожие вопросы