Looks like Apache config? It's a good idea to specify things like that. The tags confirm it though.
That config only runs when they connect on port 443, so it can't redirect from HTTP.
You can't do a 30[12] redirect in response to a POST request and keep the arguments unless you convert the request to a GET and write the arguments into the URL. Not really recommended.
You can proxy the request, but I'm not sure that solves your problem.
If the user has already submitted data via POST over an unencrypted connection, and you care about the encryption, you're probably best to let that request break anyway, so it gets noticed and fixed. You should be fixing your form target, and also making sure that the form itself (or the page with AJAX in it or whatever) is sent to the user over HTTPS.
UPDATE
Given that shawsy has said that the problem is that The browser cannot make HTTPS connections to the server, a redirect is definitely not what's wanted. Rather you want to proxy the request:
<VirtualHost 10.1.2.91:80>
# http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass
ProxyPass /GladQE/link https://glad-test.com/GladQE/link.do
ProxyPass /GladQE/retrieve https://glad-test.com/GladQE/retrieve.do
</VirtualHost>
You could alternatively do it with mod_rewrite and RewriteRule.
There are some extra issues to work out if you're changing the domain name, but I think that's not the case here.
Just as an aside, I personally don't like putting host names or IP addresses anywhere except in the server's /etc/hosts file. If you use names in the hosts file like 'web' and 'mysql', which locate services rather than machines, and you refer to those in your apache and other files, then you can move configuration between machines much more easily, knowing that you only have to go over what's in the hosts file.
Although 308 is now a standard (https://www.rfc-editor.org/rfc/rfc7538), it is not currently Safe [Edit] (as of 3 April 2019), especially for desktop applications, but may be almost safe in some specific regions (e.g. India), or for applications targeted at tablets and mobile devices.
The lack of safety is because IE 11 on Windows 7 and 8.1 does not support it. In IE 11 the site just appears to hang. Luckily the IE that shipped with Windows 10 does support it, so it will be just a case of waiting until the general populous moves on from Windows 7 (Win 7 has only just been surpassed by Win 10 in global usage stats, Win 8 is significantly less popular than both) [Edit] or your company makes a decision to no longer support it (which you can make a very strong case for from 14th January 2020 when Windows 7 loses even long term support), and even more so from 15th June 2022 when IE itself will no longer be supported (see the download page for it).
All other modern browsers support it (Chrome, Firefox, Safari, Edge, Opera).
[Edit] Usage stats from March 2019 to help make your decision:
- 36.52% of desktop users are still on Windows 7
- 9.83% of desktop users were on IE; as Win10 pushed Edge so much, I'd assume most of these users to be on Win 7.
[Edit] Usage stats from March 2022:
- 24.79% of desktop users are still on Windows 7
- 4.84% of desktop users were on IE; as Win10 pushed Edge so much, I'd assume most of these users to be on Win 7. Ref netmarketshare
So, a decision to use 308 would affect less than 5% of desktop users as of this edit (2022-03-11). If your application is geared more towards tablets/mobile devices, this value will be significantly lower. Similarly if your app is specifically for the Indian market.
You can test if your browser supports 308 redirects here: https://webdbg.com/test/308/
Best Answer
As specified in RFC 2616 Sec 10.3, if the response to a POST request is a redirect (301, 302, 303, or 307), the user agent must NOT repeat the POST at the new location.
Your only hope for repeating a POST would be for the first response to return some JavaScript that automatically re-submits the form data at the new location.
However, considering that you've already divulged the form data over cleartext HTTP, there really isn't much point to continuing the session over HTTPS. You really ought to start earlier and present the user with the initial form over HTTPS.