Redirection on Apache (Maintain POST params)

Question

I have Apache installed on my server and I need to redirect from http to https. The reason for this is our load balancer solution cannot hand https so requests come in on http and then we transfer them to https using the below lines in the httpd.conf file.

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

This works fine for GET requests but POST requests will lose the parameters passed on the URL. What would be the easiest way to perform this redirect and maintain POST params?

I need to get from http://glad-test.com/GladQE/link.do to here https://glad-test.com/GladQE/link.do maintaining POST params

Thanks

Tom

Answer 1

Standard Apache redirects will not be able to handle POST data as they work on the URL level. POST data is passed in the body of the request, which gets dropped if you do a standard redirect.

You have an option of either using a PHP script to transparently forward the POST request, or using a combination of Rewrite (mod_rewrite) and Proxy (mod_proxy) modules for Apache like follows:

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

P flag passes the request to the Proxy module, so anything that comes to your site (via GET or POST doesn't matter) with a URL path starting with a /proxy/ will transparently be handled as a proxy redirect to http://www.example.com/.

For the reference:

• http://httpd.apache.org/docs/current/mod/mod_rewrite.html
• http://httpd.apache.org/docs/current/mod/mod_proxy.html

Answer 2

You can try with the HTTP status code 307, a RFC compilant browser should repeat the post request. Reference: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For instance, a POST request should be repeated using another POST request.

To change from 302 to 307, do that:

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

Answer 3

Either your public facing website MUST use SSL to protect confidentiality or there is no sensitive data enver passing through it, and no possibility that your site will ever be used for a lauinchboard for sslstripping (there's a very good reason why Google serve up search results over HTTPS).

If you are not encrypting traffic between browser and your site then why are you trying to encrypt them between your load balancer and your webserver? If you do happen to have a SSL termination outside the load balancer (a very silly approach) then using HTTPS between the load balancer and the webserver is far from efficient. The question also implies lots of other security problems like session fixation/sniffing and SSLStripping vulnerabilities.