Перенаправление на Apache (поддержка параметров POST)

У меня установлен Apache на моем сервере, и мне нужно перенаправить с http на https. Причиной этого является наше решение балансировки нагрузки, которое не может передать https, поэтому запросы поступают на http, а затем мы передаем их https, используя приведенные ниже строки в файле httpd.conf.

<VirtualHost 10.1.2.91:80>
     Redirect 302 /GladQE/link https://glad-test.com/GladQE/link.do
</VirtualHost>

Это отлично подходит для запросов GET, но POST-запросы потеряют параметры, переданные по URL-адресу. Каким будет самый простой способ выполнить эту перенаправление и поддерживать параметры POST?

Мне нужно получить от http://glad-test.com/GladQE/link.do здесь https://glad-test.com/GladQE/link.do сохранение параметров POST

Спасибо

Tom

Ответы

Ответ 1

Стандартные перенаправления Apache не смогут обрабатывать данные POST при работе на уровне URL. Данные POST передаются в теле запроса, который отбрасывается, если вы выполняете стандартное перенаправление.

У вас есть возможность использовать PHP script для прозрачной пересылки запроса POST или с помощью комбинации модулей Rewrite (mod_rewrite) и Proxy (mod_proxy) для Apache, например:

RewriteEngine On
RewriteRule /proxy/(.*)$ http://www.example.com/$1 [P,L]

P флаг передает запрос модулю Proxy, поэтому все, что приходит на ваш сайт (через GET или POST, не имеет значения) с URL-адресом, начинающимся с /proxy/, будет прозрачно обрабатываться как перенаправление прокси-сервера до http://www.example.com/.

Для справки:

Ответ 2

Вы можете попробовать с кодом статуса HTTP 307, браузер компилятора RFC должен повторить запрос на отправку. Ссылка: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

В отличие от того, как исторически было реализовано 302, запрос метод не может быть изменен при переиздании оригинала запрос. Например, запрос POST должен быть повторен с использованием другого POST.

Чтобы изменить значение от 302 до 307, выполните следующее:

<VirtualHost 10.1.2.91:80>
     Redirect 307 /GladQE/link https://glad-test.com/GladQE/link.do
</VirtualHost>

Ответ 3

Либо ваш публичный веб-сайт ДОЛЖЕН использовать SSL для защиты конфиденциальности, либо через него не проходит конфиденциальный поток данных, и нет возможности, что ваш сайт когда-либо будет использоваться для lauinchboard для sslstripping (есть очень веская причина, почему Google обслуживает результаты поиска через HTTPS).

Если вы не шифруете трафик между браузером и вашим сайтом, то почему вы пытаетесь зашифровать их между вашим балансировщиком нагрузки и вашим веб-сервером? Если у вас действительно есть завершение SSL за пределами балансировки нагрузки (очень глупый подход), то использование HTTPS между балансировщиком нагрузки и веб-сервером далека от эффективности. Этот вопрос также подразумевает множество других проблем безопасности, таких как фиксация сеанса/обнюхивание и уязвимости SSLStripping.