Forum Moderators: phranque
I decided eventually to disable ssl on one of the sites. But now it keeps wanting to redirect a path /user/ to 443 default ssl whenever i want to login? i've tripled checked everything 1000x and disabled every other vhost in my httpd.conf. there is NOTHING ssl related to this vhost in any way shape or form. but it still want's to do a 302 redirect when it attempts to authenticate the uri 'user/' after submitting the form?
I'm literally pulling my hair out because i need to have this thing running.
To the best of my knowledge, it's almost as if that user path is cached or something which makes it go to the prior config of https. But i've cleared the browser 200x times, restarted it and tried this login on FF, IE and Opera all with the same 302 redirect to 443 default https. Maybe the server is caching the info?
Before i post anything conf files, i'm wondering if anybody has any thoughts on this or is willing to help. I would appreciate it mightily. I've searched the web high and low and scoured the apache manuals and played with my config for 40+ hours to try to get this working. This shouldn't be that difficult.
This absolutely makes no sense at all.
thanks much
I don't think that's an option. SSL uses port 443, and trying to use other ports may give you even bigger problems down the line, especially with clients (browsers and 'bots) which expect the standard port. SSL typically demands IP-based virtual hosts, rather than name-based vhosts.
Be aware that in the general case --regardless of SSL issues-- Apache will default to the first-defined vhost if it does not find a vhost for the requested hostname. This could be a factor in what you're seeing.
Other than that, it's a matter of tracking down the source of the 302 redirect. Since 302's are rarely-used on well-designed sites, this shouldn't be too hard. Possible sources might be:
When "clearing a browser", be sure you are using the "delete cache" or "delete temporary internet files" dialog -- Forcing page reloads is often insufficient.
The "Live HTTP Headers" extension for Firefox/Mozilla browsers is a very good tool for client and server HTTP header checking. This might reveal whether the 302 redirect to SSL happens immediately, or at the end of a chain of (other unexpected) redirects.
Jim
>> using ssl on multiple ports> I don't think that's an option. SSL uses port 443, and trying to use other ports may give you even bigger problems down the line, especially with clients (browsers and 'bots) which expect the standard port. SSL typically demands IP-based virtual hosts, rather than name-based vhosts.
if you read the documentation closely, it actually says you CAN do it with ports BUT.. it doesn't tell you how and i couldn't find it documented anywhere so i decided i would try to see if i could get it to work on my own with some grit.
The KEY is that "every ssl vhost must be able to communicate on it's own "channel"". If you set up each vhost to listen to it's own ssl on a unique port, eg 443, 4430, 4431, etc, and then use mod_rewrite to redirect back and forth on given request URIs for given domains, it actually works! At least i got most of this working for about 7 or 8 vhosts. It's SLOW THOUGH! because there's a lot of rewriting and then redirecting going on for every request. And because i'm only delivering ssl on certain request uri's (e.g. user, admin, etc) that makes more processing.
This is somewhat an aside to my post though.
RIGHT NOW!, my problem is that i've disabled SSL on all my vhosts but they still want to go back to using ssl on some of the paths for that vhost (like 'user/login' - anything under user for that matter, etc). I've also turned off all of my vhosts except for 2 of them to help isolate the problem. Currently 1 vhost (the one with the phantom ssl redirect) is a dynamic php generated site. The other is a very basic *:80 default vhost which is a single page html file.
So i'm utterly puzzled. Whenever, i hit what USED TO BE A SSL REDIRECTED PATH IN THE OLD CONFIG (e.g. /user/*) i still get redirected to ssl. However, now it drops down to the default ssl vhost at *443 and then fails. Oddly enough. If i try path "admin*", which also used to be SSL redirected, it does NOT reroute me to the default ssl?
So it appears that something is being cached.
Can apache cache?
Be aware that in the general case --regardless of SSL issues-- Apache will default to the first-defined vhost if it does not find a vhost for the requested hostname. This could be a factor in what you're seeing.
yeah. that appears to be what's happening. however, i would think it would route to my default *:80 vhost and not _default_:443. Include conf.d/*.conf (the location of my ssl.conf file) does come *before* my *:80 vhost declarations though.
apache wouldn't route to *:443 over *:80 would it if the domain wasn't redirected to https explicitly?
Other than that, it's a matter of tracking down the source of the 302 redirect. Since 302's are rarely-used on well-designed sites, this shouldn't be too hard. Possible sources might be:
I'm looking into this now. Here's a separate question for you. I've noticed some 404 not found errors on images and js files that had incorrect paths. when an html page is requested and IS found but the some of the objects it contains are NOT found, apache doesn't redirect to try and find them at the default vhost does it?
SIDENOTE:
One of the side effects of my ssl vhost via port setup above was that when i DID redirect to ssl load a uri, every object contained on the page (images , etc) were also fetched over ssl (prefixed with https). That is why the technique was so slow. I guess that's normal behavior and makes sense? the entire http fetch is encrypted/encapsulated in the ssl packet. But it' really inefficient if you don't care about images and stuff being encrypted.
# Domain "forwarding" or "pointing"
# Incorrect syntax on ErrorDocument directives (see documentation)
# Incorrectly-coded Redirect or RewriteRule directives used for domain canonicalization
1) I'm not forwarding the domain. I am redirecting non www to www based site so i don't think this is the problem.
2) ErrorDocument . This might be it?
3) My redirect rules are set back to the way they originally were before i added ssl and are quite thoroughly tested so i don't think that's the problem.
When "clearing a browser", be sure you are using the "delete cache" or "delete temporary internet files" dialog -- Forcing page reloads is often insufficient.
I've gone into the options to clear this stuff out the right way on all browsers. So i'm not sure what's happening here. I will say this, my IE browser seems to still cache previous domains in the url bar even though i clear the all the files (temp file) and history in options
The "Live HTTP Headers" extension for Firefox/Mozilla browsers is a very good tool for client and server HTTP header checking. This might reveal whether the 302 redirect to SSL happens immediately, or at the end of a chain of (other unexpected) redirects.
I guess i should look into that. I use firebug and the 'net' tab to see http headers.
thanks for any input you can provide
Using firebug i can sort of see what's happening:
[host...] -> works fine, it brings up the login form
if i type in wrong info and submit, the php app validates the form fine and returns to [host...] -> works fine
The problems starts the minute I enter BOTH a valid uid AND password. The code validates the user and gets ready to route them to their user home page at:
[host...]
The number is the user id and would be different depending on which uid was being authenticated.
It's at this point that i'm presented with an ssl popup to accept or decline my self-signed certificate which belongs to vhost _default_:443.
As i said, the 443 https vhost is doing it's job correctly and presenting the appropriate cert. the problem is that no part of my apache conf is rewriting or redirecting to go to the 443 vhost!?
hope that's more clear. what sucks is i can't log into my app
I have completely disabled the ssl.conf from my apache Include. Meaning that there is no SSL running on my apache server.
yet when i try to login at path "/user/login", the minute my app trys to authenticate the user, it redirects to https?! how can that be if my apache server has no ssl enabled?
Fyi i have restarted apache a gazillion times to make sure my setting have taken effect and cleared my browser session, cookie and browser caches a trazillion times as well as made attempts across different browsers and different systems. that seems to tell me that the server is caching something? Where what and how?!
Any gurus out there?
Well, you've left me completely stumped up to here, but that sounds like the application itself is generating a redirect to HTTPS...
Jim
