Preface

Firstly: A simply Port 80 -> Port 443 Rewrite WILL NOT fix this. In almost every previous question, mail thread, forum thread, etc., I have found this was the first ignorant response and was parroted several times.

Secondly: Yes I know you cannot serve HTTP and HTTPS traffic on the same port. This is not that.

My Question is, how in the name of Zeus's butthole can you modify Apache's behavior or this error message to redirect the user automagically?

Apache is obviously serving a non-https request (to display that error message) even though it is configured for HTTPS. It seems remarkably dumb to me to not just do the redirect by default, but I can understand why they went with the behavior they did, even if I don't agree with it. So my question is: can you change it? They are handling the error SOMEWHERE, and with Apache being the configuration cornucopia that it is, it stands to reason there is some directive somewhere to handle this behavior, but I have been unable to find it in several hours of tinkering so far.

Update:

I have attempted a variety of things including:

using ErrorDocument 400 directives to get to a CGI and a PHP script that just send Status 301 and Location headers. This results in a blank page. Using ErrorDocument 400 https://hostname.tld:7443 simply results in that link being displayed on the page.

Using almost every combination of mod_rewrite I or Google can come up with, including blanket statements that direct the site entirely; these never work. Literally, they do nothing. I'm surmising that Apache is kicking to the above error before even attempting to process the rewrite directives.

I can't use port-based redirects, because of the custom port use. I can't use script-based redirects because they never get served because of the http/https mismatch. I'm almost willing to chalk this up to a bug, or an unintended behavior, but somebody had the forethought to put a very custom error message in there, they didn't bother thinking that maybe you'd want to just cart to the URL they are already providing?

Daniel, That was one of the many questions I had found and solutions I had attempted before posting this question. I think the problem was the PHP component, but since @hrunting's answer's update is working beautifully for me at the moment, I'm not going to sink any more time into it than I already have; at least not until I have to.
–
peelmanFeb 11 '13 at 1:19

Then I get the HTML for a 302 redirect, but again, none of the headers. Without the 302 redirect response code and the Location: header, the browser won't redirect.

Try upgrading to Apache 2.4 and see if it works. I've tested and confirmed with at least Apache 2.4.3, but I haven't gone through the effort of finding exactly when this was behavior was updated. I suspect that in the large amount of work they did preparing 2.4, they corrected the undesirable behavior as a side-effect.

You can force a buggy Apache to give you the behavior you want (the redirect) by having the script print out its headers (which will not be sent to the client), and then manually print out again the headers you want. Here's a basic Perl script that works under Apache 2.2.22:

#!/usr/bin/perl
use strict;
use CGI;
my $q = CGI->new();
# this will cause Apache to handle the response properly, but is meaningless otherwise
print $q->redirect("https://localhost/");
# this actually performs the redirect
print "HTTP/1.1 302 Found\r\n";
print "Location: https://localhost/\r\n";
print "\r\n";
# you can do whatever you want here; this will be the HTML body

You should be aware that there are other reasons a 400 may be generated besides just talking to an SSL port without SSL. The easy way to determine this is to look for the HTTPS environment variable. If it's set, then SSL was negotiated properly and something else is causing the 400 (don't do the double header trick if that's the case). If HTTPS is not set, return your redirect as above.

You know, as I read this, I think to myself, "Man, it really sucks if you have Apache 2.2 and you want this kind of redirect behavior." I'm not going to go through the effort of finding an appropriate Apache 2.4 deb (or making my own) for my Ubuntu system. I bet you can hack a solution from your PHP script. Apache's clearly just dumping the output to the client, so if you return the specific expected content, I bet you can get the behavior you're looking for without upgrading Apache. Try having your PHP script print out "HTTP/1.1 302 Found\r\nLocation: server.tld\r\n\r\n".
–
hruntingFeb 10 '13 at 4:17

The problem there is that it doesn't appear that the PHP script is getting processed. I should note that this is current sitting on Apache 2.2.22 on Ubuntu Server 12.04. And yes, it really, really sucks; especially when you note that in those bug reports, they seem to be completely set against even providing an option to just automatically do the redirect, and there doesn't appear to be much hope that 2.2 will ever be getting the fix.
–
peelmanFeb 10 '13 at 4:20

And like I said up above, it just doesn't make sense to me why you go through the trouble to write that error message, rather than redirecting to secure (seriously, why not just redirect? the more I think about it, the less I think that is a bad idea).
–
peelmanFeb 10 '13 at 4:23

Are you sure the PHP script isn't getting processed? Because you get no output instead of the standard output, I bet it is getting processed. My bet is that it is getting processed, it's just not dumping out exactly the right data that's necessary (using PHP function calls probably assume that the web server is going to do the "right thing" which it isn't in this case). I bet if the header content were output as the body instead of normal headers, it would work.
–
hruntingFeb 10 '13 at 4:25

Nope, I already tried that, it doesn't work. Its like it doesn't even get to the ModRewrite steps because its hitting the http/https mismatch first.
–
peelmanFeb 9 '13 at 22:47

Hrm so I assume you have started from the top of you apache config file and worked your way down to see what it is calling
–
trentFeb 9 '13 at 22:52

I have practically memorized the entire sites-available directory. Even if you just redirect it to nonsense, or redirect it to a different site, different port, etc., it just keeps loading that 400 Bad Request.
–
peelmanFeb 9 '13 at 22:59