22

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

András Aszódi
  • 8,948
  • 5
  • 48
  • 51
shawsy
  • 457
  • 1
  • 6
  • 23
  • If you get http -> https redirection working for POST requests, be sure not to send any sensitive data in the initial, insecure (http) post! This can lull the user (and perhaps the developer) into a false sense of security, while all the data is initially being transmitted in plaintext! – Neal Gokli Jun 16 '17 at 01:54

3 Answers3

34

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>
Lorenz
  • 2,179
  • 3
  • 19
  • 18
  • 2
    Actually, HTTP Redirect 308 should apply here, as the OP wants subsequent requests to be posted to the HTTPS URI. – parasietje Feb 18 '14 at 14:39
  • 1
    And HTTP 308 status code is not supported in all current browsers. Therefore, use 307 instead. Source: http://greenbytes.de/tech/tc/httpredirects/#t308methods – parasietje Feb 18 '14 at 14:40
  • @parasietje Besides that 308 isn't supported in all browsers, the OP uses currently HTTP 302 which means "Moved Temporarily", so 308 would do something different. 307 is "Temporary Redirect", which is the same as 302 but keeps the request method. – Lorenz Feb 18 '14 at 20:47
  • @parasietje That test page is now outdated or was wrong in the first place. MSIE11 and Edge 14 do support status 308, as can be seen in the live test on that page. – ygoe Dec 29 '16 at 12:24
  • @ygoe It's still an issue if you need to support older browsers... I wasn't able to find information about what versions added support. – Neal Gokli Jun 19 '17 at 17:53
  • Redirect 307 is a fantastic trick! Thanks, this answer is much better than the accepted one. – f055 Mar 19 '20 at 15:48
20

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:

dezlov
  • 840
  • 8
  • 20
  • 2
    Perfect, works for me - when doing this for https, you need to add SSLProxyEngine on in your configuration – mark Oct 03 '18 at 09:41
0

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.

shawsy
  • 457
  • 1
  • 6
  • 23
symcbean
  • 47,736
  • 6
  • 59
  • 94