Having a bit of trouble tracing down the cause of this annoyance. I have the following Redirect in one of my virtualhost conf files
Redirect permanent / https://mysite.com/
It works perfectly when I go to
But if I go to …
it bypasses the redirect completely and serves plain http on port 80
now, once it’s serving and using port 443, it continues to do so as expected.
So, if I initially go to just mysite.com, all is well. But I cannot guarantee visitors will do this so I need it to redirect to port 443 properly regardless of the URL they use to enter the site.
The problem only arises if I connect to mysite.com using any CFM file INITIALLY
I’m guessing that without a “CFM” file, the server treats it as it would any other non “CFM” file.
But once I designate a CFM file, MOD_CFML is intercepting before the redirect.
But again, once connected via port 443, it will continue to serve via port 443 for the rest of the Session.
What would you suggest I look at?
In your host configuration, you need something akin to
ProxyPassMatch ^/(.+\.cf[cml])(/.*)?$ ajp://localhost:8009/$1$2
This tells your apache server that files named .cfc .cfm or cfml are to use lucee and not directly serve them as plain text.
This is already in the apache2.conf
CFML is already working, just not redirecting to port 443 under the specified conditions.
ProxyPassMatch ^/(.+\.cf[cm])(/.*)?$ http://127.0.0.1:8888/$1$2
ProxyPassMatch ^/(.+\.cfml)(/.*)?$ http://127.0.0.1:8888/$1$2
# optional mappings
#ProxyPassMatch ^/flex2gateway/(.*)$ http://127.0.0.1:8888/flex2gateway/$1
#ProxyPassMatch ^/messagebroker/(.*)$ http://127.0.0.1:8888/messagebroker/$1
#ProxyPassMatch ^/flashservices/gateway(.*)$ http://127.0.0.1:8888/flashservices/gateway$1
#ProxyPassMatch ^/openamf/gateway/(.*)$ http://127.0.0.1:8888/openamf/gateway/$1
#ProxyPassMatch ^/rest/(.*)$ http://127.0.0.1:8888/rest/$1
ProxyPassReverse / http://127.0.0.1:8888/
Try that in the virtualhost, not the main config.
I tried that several weeks ago. Seemed a good possibility. But didn’t change anything.
Seems it’s working from the apache2.conf, otherwise no CFM would be served at all.
You need to have a separate entry for your site running https , ie 443 in the base configuration for mod_ssl’s default virtualhost.
You mean in sites-available don’t you?
I already have
The latter designated with
Each enabled in sites-enabled
(Everything works fine EXCEPT…if I initially upon entering the site I specify a CFM file. If I specify an HTM file or any file OTHER than a CFM file, it properly redirects to 443)
But even in that case, once I’m inside the site and click on a link to ANY other CFM file, it stays on port 443
It just seems to not know what to do upon FIRST CONNECTION if I specify a CFM file in the URL
Without having full access to either your server or complete configuration files its like trying to solve a puzzle without knowing anything about it other than someone describing some of the pieces to you.
If your our issue is:
If you go to mysite.com it redirects to https://mysite.com/ & runs index.cfm (as it should)
if you got to mysite.com/foo.cfm it does not redirect to https://mysite.com/foo.cfm
Virtualhost: * 80
RewriteRule (.*) https://foo.com$1
Yes it is. And your help is appreciated.
Your last suggestion seems to have done the job.
MUCH appreciated Terry.
mod_cfml handles the initial request by responding with a redirect back to your original request (so you can hit the context you were originally going for). Is that not happening here? Are you getting the redirect response after the initial hit? That next hit should hit your apache config. If it doesn’t, you might be hitting an apache order of execution problem, where the proxy config is being hit before your redirect config.
Using the ‘curl’ Linux command or your browsers developer tools is really useful in situations like this. For example:
curl -v http://mysite.com
… should let you see if you’re getting a redirect response or not.
My suspicion is that the Apache config isn’t working as intended. Again, a verbose curl would tell you that.
Hope this helps!
You can’t redirect a POST request…