Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

Scenario:

Apache Server hosting multiple sites via port multiplication. Port 80 serves a public site. Port 443 serves the secure version of that site.

Ports 7443, 8443, and 9443 each serve separate SSL-Secured sites.

If a user mistypes the URL, or is given a link that isn't valid, say http://hostname.tld:7443, they are given the following ridiculous page:

Apache Bad Request error message

Instead of the server just redirecting them over to https://hostname.tld:7443.

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?

share|improve this question
    
    
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. –  peelman Feb 11 '13 at 1:19
2  
upvote for the linked video, it conveys my emotions perfectly –  michele b Jul 10 '13 at 10:42

2 Answers 2

up vote 5 down vote accepted

I think this is probably a bug in how Apache 2.2 and lower handles this particular circumstance.

It seems that on an SSL read 400 Bad Request error, Apache 2.2 doesn't return the HTTP response code or headers, only the HTTP response body. I test by telnetting to port 443 and sending:

GET / HTTP/1.1

The server immediately returns (for me):

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://server.tld/"><b>https://server.tld/</b></a></blockquote></p>
</body></html>

Note the lack of an HTTP response code or any HTTP headers.

When I do this to an Apache 2.4 server, I get:

HTTP/1.1 400 Bad Request
Date: Sun, 10 Feb 2013 00:47:23 GMT
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.0g
Content-Length: 462
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
</p>
<hr>
<address>Apache/2.4.3 (Unix) OpenSSL/1.0.0g Server at server.tld Port 443</address>
</body></html>

If I setup an ErrorDocument line like you did:

ErrorDocument 400 https://server.tld/

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.

Relevant Apache httpd bugs:

UPDATE

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.

share|improve this answer
1  
Holy. Crap. Perfect Answer. Gracias. –  peelman Feb 10 '13 at 4:09
    
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". –  hrunting Feb 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. –  peelman Feb 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). –  peelman Feb 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. –  hrunting Feb 10 '13 at 4:25

You can fix this with mod-rewrite. Set a rule to match anything. See this answer on Stackoverflow

share|improve this answer
    
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. –  peelman Feb 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 –  trent Feb 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. –  peelman Feb 9 '13 at 22:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.