Forum Moderators: phranque
I have put together a very simple mod_rewrite redirect (in Apache 2.0 running on Solaris 9) that is supposed to take a request to [mail.somedomain.com...] on port 80 and redirect it to an https request on port 446, [mail.somedomain.com:446....] It works for Mozilla and other clients, but fails to work with IE 6.0. Here is the code:
<VirtualHost *>
ServerName mail.somedomain.com
ServerAlias mail.somedomain.com
UserDir disabled
RewriteEngine On
# route to [mail.somedomain.com:446...]
RewriteRule ^/(.*) [mail.somedomain.com:446...] [L,R]
RewriteLog /usr/local/apache/logs/mail-rewrite.log
RewriteLogLevel 9
</VirtualHost>
I did some searching on the net for a solution to this problem, and came accross some references to the "keepalive" apache directive not working well with older versions of MSIE when doing a 302 redirect to https, but nothing with regards to version 6. I also found the following in the httpd.conf file:
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
which I thought may help. I commented out this line and changed it to:
BrowserMatch "MSIE" nokeepalive downgrade-1.0 force-response-1.0
in hopes of capturing all MSIE browser levels, but it didn't resolve the problem. I changed the redirect from https to http on a non-secure port and it worked, so this is indicative of a problem redirecting to https for IE clients.
Any help would be GREATLY appreciated.
Best Regards,
SR123
Okay, found the following with more troubleshooting. I changed the technique I was using for the redirect from using mod_rewrite in the virtual host directive, to just using PHP to the the redirect.
Here is the new virtual host directive:
<VirtualHost *>
ServerName mail.somedomain.com
ServerAlias mail.somedomain.com
DocumentRoot /usr/local/apache/htdocs/.../mail.somedomain.com UserDir disabled
AddType image/x-icon .ico
CustomLog logs/mail.xsmsystems.com combined
DirectoryIndex index.php index.php3 index.html index.htm *.htm
</VirtualHost>
in the /usr/local/apache/htdocs.../mail.somedomain.com dir I have an index.php file with the following code in it:
<?php // The sole purpose of this page is to
// redirect the user to the following URL:
// [mail.somedomain.com:446...]
header("Location:https://mail.somedomain.com:446");
?>
When I retried going to [mail.somedomain.com...] from IE it still failed to load the page but it worked in Mozilla, again.
This seems to suggest that regardless of how I do the redirect, IE can't handle it.
One other interesting caveat. We are using a self-signed certificate on the redirected-to URL on port 446. IE and Mozilla both have no problem when you type the URL into the Address bar directly, so the cert itself is not the problem. But, I tried redirecting to another https page, namely login.yahoo.com, and it WORKED in IE, whereas redirecting to the site with the self-signed cert failed.
Regards,
SR123
Jim
Thanks for the reply. I'll check out the cert, although as I mentioned, if I simply type the URL in by hand into the browser:
It loads up fine, even with the self-signed cert.
It only fails to load upon redirection from http to https. The cert gets presented and I accept it, but then I get the page not found error... Totally bizarre, because it works fine when I use Mozilla.
To summarize the problem symptoms exactly:
1) Going to [mail.somedomain.com...] is setup to redirect to [mail.somedomain.com:446...] using the methods described in my first two posts for this thread.
2) Works from Mozilla, doesn't work for IE, and that's for BOTH the techniques I used for the redirect.
3) Typing [mail.somedomain.com:446...] in the address bar WORKS for both Mozilla and IE.
4) When I change the redirection to a site that has a signed cert from a valid authority it works in both IE and Mozilla.
Regards,
Sam
<?php
if($HTTP_SERVER_VARS["HTTPS"]!= "on")
{
$newurl = "https://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"];
header("Location: $newurl");
header("Connection: close");
exit();
}
?>
This PHP will redirect the browser to the secure version of the page if they aren't on a secure connection. The only key line is the line that adds the "Connection: close" response header to tell IE it *must* close its keep-alive connection. It's a bug in IE. If this doesn't happen then IE thinks it can use its current connection to retrieve the redirected content. This can't happen, because it needs to re-establish a HTTPS connection.
Regards,
-Kevin