Is there an Apache/Plesk server setting that governs https:// behavior? - apache

Context:
I've recently moved a site to a new host, and moved the SSL certificate from the old host to the new one. The code, written in PHP, is a big mess made by someone no longer available many years ago. Because of this, I'm hoping to figure out something related to the configuration of the server that can fix the issue so I don't have to reverse-engineer the rather messy code.
Problem:
When users navigate to an area of the site that uses https://, all goes according to plan. The problem, however, arises when they click a link in the navigation that is normally to an http:// part of the site. On hover, you can see that the target URL incorrectly includes "https://". When the user tries to go to a non-secure area with https:// in front, either by clicking one of those altered links or by typing it into the location bar of the browser, they are redirected to the directory without any domain. For example, if you try to go to "https://domain.org/site/", the browser is redirected to only "/site", which of course cannot be found.
Theoretical solutions:
Is there a setting in Plesk which governs the "stickiness" of https? One way to fix the problem is to stop the non-secure links from acquiring https://.
Is there an obvious reason why whatever script or file the site is using to redirect would break when an un-secure area is accessed via https://? Is there a server setting that would have made this function differently on the new server via the old server?
I don't have access to see what exactly the configuration of the old server was. Is it likely that this could be caused by a difference in PHP version? If so, any suspicions about what the problem would be?
Is there some workaround with .htaccess that can manually redirect all but certain secure areas of the site to http:// when they are accessed via https://, presumably before the site's redirect script is activated?
Thank you for any help!!

Yes, since Plesk 17 (Onyx):
For older versions you can create .htaccess files which will rewrite request from https pages to http, based on referrer:
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^https://domain.org [NC]
RewriteRule ^(.*)$ http://domain.org/$1 [L,R=301]

Related

HTTP access was forced to visit HTTPS

I have a few web sites that are hosted in a VPS.
Today, I found that when visiting "http://api.rsywx.com", it forces me to visit "https://api.rsywx.com", and the redirects me to "https://rsywx.net" (which is SSL enabled).
I checked my virtual host files, and did not find out anything forcing this redirect.
Anyone can point me some direction on how this can happen?
Redirects can be done on different ways and levels. Most elegant ways in descending order (my opinion):
Apache conf (mostly in /etc/apache2/apache2.conf)
.htaccess - file
in the index.php or the used backend script/code
(- could be even done in the frontend with javascript files but for that the page must be loaded and then will be redirected.. So nothing somebody should use)
Problem solved. I added one line in my Silex application's entry index.php to require HTTPS access, which is meant to be locally tested only.

htaccess not working with ~username Path

I am working on a new website, which still has to be connected to a domain name via DNS. So, at the moment I am working with http://ipaddress/~username/public_html/
I am having a problem with making internal redirects work in my htaccess file, which sits at http://ipaddress/~username/public_html/
I need to map http://ipaddress/~username/public_html/work/ to http://ipaddress/~username/public_html/projects/index.php
Here is what I have:
RewriteEngine On
RewriteBase /~username/public_html/
RewriteRule ^work/?$ projects/index.php?$1 [L,NC]
The problem is that I always get a 404 error with the above.
How can I make this work properly?
UPDATE
This seems to have to do with how the server handles the redirects if a DNS record does not exist yet. In other words, since this is a development site, a domain has not been connected with the site. Once that has been set up, everything is working.
This seems to have to do with how the server handles the htaccess redirects if a DNS record does not exist yet for the site. In other words, since this is a development site, a domain has not been connected with the site and relative paths were used. Once that has been set up, everything is working.

apache keeps old .htaccess settings (in rewriterule)

I am testing some basic .htaccess rewriterules and I am pretty sure that even after deleting a rule in .htaccess and saving the document, apache ignores it and acts like the rule was still there (only for earlier requested sites) - even after apache restart. It is driving me crazy, the behavior is really mad. Is there any apache cache which is about to be cleaned or the problem is elsewhere?
It's madness! Not really, it's just annoying.
When you set a redirect in Apache what you're doing is actually configuring headers that are passed to your browser. Your browser keeps a cache of 301 and 302 redirect headers (and other things like DNS) in the event you go back to those pages, so it can save you time. 301 redirects are supposed to be permanent (that's what you're indicating), so if there is no need for the browser to do something like perform a DNS lookup or visit a page based on a redirect, then it will cut corners and use the cache in order to provide you with a faster browsing experience.
You need to flush your browser's cache to prevent the store redirects from happening.
Additionally, you'll want to resubmit your page to Google (in the event it's on the web) in case they've crawled your site while the invalid headers existed.

Apache htaccess redirect

about a year ago, I moved a whole website to a new server. I still have access to the old server (which has a lot of junk on it) and I would like to have the old site redirect to the new one (they have different domains). The old server is running Apache. I thought something like this could be done via the .htaccess file so I put the following as my .htaccess file:
Redirect 301 / http://newsite.com/
This did not work and, upon accessing the old site, I got a "500 Internal Server Error".
I would rather delete the files from the old server. The problem is, though, that I am afraid that (since they are ranked pretty high on Google) if someone clicks on a link to one of those files, he will just get a "404 File Not Found Error". I just want to edit the .htaccess so that every file path on it will redirect to the new site. If you know how to do that, please help me. Thank you!
You should consider using mod_rewrite instead, assuming it is enabled on the old server:
RewriteRule ^(.*)$ http://newsite.com/$1 [R=301, L]
This preserves and appends the path to the new host

Issues with FastCGI and links containing index.php? versus index.php

On a Windows 2003 server running IIS 6.0 and FastCGI with an ExpressionEngine-powered website, I've encountered an issue where links containing index.php fail unless a question mark is added.
The basic issue is that if a link points to "index.php/archive/article", the page fails to load (see below) but it will work when "index.php?/archive/article" is used.
What happens when the "index.php" links fail is the URL will change in the browser address bar, but the main page content is still displayed. Append a question mark to "index.php" and the page loads properly.
The site was previously running with ISAPI as the Server API with no issues: the server saw "index.php" and "index.php?" as being synonymous and pages with "index.php" in the path would load as expected.
How would I configure setting somewhere which would tell FastCGI to treat "index.php" and "index.php?" the same way?
I am a bit green when it comes to Windows servers; my experience is mostly with Apache servers running on Unix boxes.
Any guidance or pointers would be most appreciated.
One option is that you could simply enable EE's force URL query string option.
But, if you don't like having the question mark in the URL, you can try this workaround.
I can't say that I know anything about Windows servers, but this has worked for me on Apache servers when running PHP as CGI. Best of luck!