Unwanted Apache redirect behavior - apache

My Apache installation on my Ubuntu 12.04 server redirects requests addressed to:
http://87.73.120.126
to
http://90.184.18.96/joomla/index.php/jomsocial
The address 87.73.120.126 is my servers current IP-address. The address 90.184.18.96 was the one it had half a year ago.
My question is: why does it do this? and how do I make it stop?
Half a year ago I wanted to make requests to http://90.184.18.96 redirect to http://90.184.18.96/joomla/index.php/jomsocial
I did this by adding this line:
RedirectMatch permanent ^/$ http://90.184.18.96/joomla/index.php/jomsocial
to the file /etc/apache2/apache2.conf
A couple of days ago I tried to solve the current redirect problem by changing the line above to:
RedirectMatch permanent ^/$ http://127.0.0.1/joomla/index.php/jomsocial
and rebooting the server. This did not solve the problem!
Then I tried to do a global file search for the string 90.184.18.96 using this command:
sudo grep 90.184.18.96 / -irn --exclude-dir={bin,lib64,opt,sbin,tmp,boot,lost+found,proc,selinux,dev,media,root,srv,lib,mnt,run,sys,mail,log,doc,src,recovery-mode} --color
this search revealed a couple of outdated CRON-entries that I also fixed to use 127.0.0.1 instead. This didn't help either. So, where could the string '90.184.18.96' be residing? I guess it must be somewhere in order for anything to redirect to that address.
This server runs Joomla from the path /var/www/joomla/. As this path is not excluded by my grep-search any redirection emerging from Joomla should be revealed by the grep-search.

Two considerations:
Redirecting to 127.0.0.1 will redirect to the user's machine, not your server. If you're only spanning one server, you should not include your server's IP (it's not nice to access a site with a domain i.e. www.your-domain.com and be redirected to an ip address). So the rule should use variables for the host: %{HTTP_HOST} and %{REQUEST_URI} for host and path.
Besides httpd.conf you may also have redirect rules in your .htaccess which resides in the webserver root: and it's a hidden file so it could have been skipped by your grep, have a look into that as well. Beware the syntax of .htaccess and httpd.conf is slightly different.
You're achieving two things with that redirect: point to an installation which is off-root (/joomla) and setting a different homepage. Setting the homepage in Joomla is as easy as marking its menu item with a star in the menu item editor, so you might not need the second part.

Related

Rewrite subdomain.domain.com to domain.com/subdomain without redirect

I've read plenty of Stackoverflows but I seem to be missing something.
I have a PHP application running on https://subdomain.example.com/page/x but for SEO reasons I want people/bots to see https://example.com/subdomain/page/x.
I can rewrite the URL by using:
RewriteEngine on
RewriteCond %{HTTP_HOST} subdomain.example.com
RewriteRule ^(.*)$ https://example.com/subdomain/$1 [L,NC,QSA]
This rewrite results in: https://example.com/subdomain/page/x, but I keep recieving a 404 error since the "main" domain doesn't know the path /subdomain/page/x of course.
What I want is to have the URL https://example.com/subdomain/page/x but run it on https://subdomain.example.com/ in the background since this is the place where the PHP application is running.
Is this possible? How should I do this?
There is no strong SEO reason not to use subdomains. See Do subdomains help/hurt SEO? I recommend using subdirectories most of the time but subdomains when they are warranted.
One place where subdomains are warranted is when your content is hosted on a separate server in a separate hosting location. While it is technically possible to serve the content from a subdirectory from the separate server, that comes with its own set of SEO problems:
It will be slow.
It will introduce duplicate content.
From a technical standpoint, you would need to use a reverse proxy to on your example.com webserver to fetch content for the /subdomain/ subdirectory from subdomain.example.com. The code for doing so in the .htaccess file of example.com would be something like:
RewriteEngine on
RewriteRule ^subdomain/(.*)$ https://subdomain.example.com/$1 [P]
The [P] flag means "reverse proxy" which will cause the server to fetch the content from the remote subdomain. This will necessarily make it slower for users. So much so that it would be better for SEO to use a subdomain.
For this to work you would also need to leave the subdomain up and running and serving content for the main server to fetch. This causes duplicate content. You could solve this issue by implementing canonical tags pointing to the subdirectory.
This requires several Apache modules to be available. On my Debian based system I needed to run sudo a2enmod ssl proxy rewrite proxy_connect proxy_http and sudo service apache2 reload. I also had to add SSLProxyEngine on in my <VirtualHost> directive for the site I wanted to use this on.

http://localhost:80 class not registered

I installed Bitnami wamp stack, and, though my installation is reachable by http:// [nameofmylaptop]/site , i have the following error each time I launch apache :
http://localhost:80
Class not registered
I can't find anything relating to this..
Any help ? Thank you.
Have you tried: localhost/site, it could be that since your website is in a subfolder called site, localhost root directory has nothing to display.
#Husman Yeah it works.
Theres your problem then, there is nothing in the root folder, you can have an apache redirect to take you from localhost to localhost/site, and that should fix your issue.
There are multiple ways to redirect:
use a server side script (index.php)
use .htaccess rewrite rule
RewriteEngine On
RewriteRule ^$ /site[L]
use apache config httpd.conf to redirect from one folder to another
Redirect permanent / http://git.example.com/git/
...

Using fall-through rewrite for mod_vhost_alias

I run a couple dozen sites on my test VPS, and currently use mod_vhost_alias to avoid needing a new VirtualHost every time I throw up a new site. My current configuration looks like this:
<VirtualHost *:80>
ServerName my.servername.com
ServerAlias *
VirtualDocumentRoot /var/www/%0/public_html
</VirtualHost>
Inside my /var/www directory, each site has its own directory. For instance, the path to my personal page is /var/www/personalsite.com/public_html/index.php. This is working great for requests to http://personalsite.com.
However, this does not work when requests come in for http://www.personalsite.com. For some of my other sites, I have the inverse problem -- the directory may be /var/www/www.sitename.com/public_html, so requests for http://www.sitename.com are fine. However, requests for http://sitename.com do not work.
Is there a way to set up my Apache config so that when a request comes in, it does the following? Are there any performance implications of doing it this way?
In pseudocode:
1. Check if the directory or file exists. If it does, skip the rest of the rules
(but don't stop, in case a local .htaccess has rules in it for pretty URLs
in WordPress or Concrete5)
2. If the file/directory does not exist:
1. If the host header starts with "www":
1. remove the www from the host header and try the first rule again.
2. If the host header does not start with "www":
1. add "www" to the beginning of the host header and try the first rule again
3. If it still fails after trying both conditions:
1. Go to a 404 error page
I'm currently doing this with about 20 virtualhosts, but that seems ridiculous when I have to add a new one for each site. The point of using mod_vhost_alias was to avoid needing all these VirtualHosts in the first place.
Assuming you're OK with redirecting users, you can use one of the techniques from https://stackoverflow.com/a/2361508/881615:
either set a mod_rewrite rule to remove the leading www. from requests,
or set a redirect in each vhost to redirect requests with a leading www. to the top-level domain

Virtual Hosts (Apache) with mod_rewrite issues

I am trying to fix this whole day without success, so I hope someone might be able to help me. I have an app at http://localhost/, and it uses Pylons for the app I am hosting. In addition to that, I need to host a PHP/MySQL site, so I had to use Apache too.
My current setup is that I use haproxy with this config for the Apache backend:
backend apache
mode http
timeout connect 4000
timeout server 30000
timeout queue 60000
balance roundrobin
server app02-8002 localhost:8002 maxconn 1000
This is triggered by this:
acl image url_sub images
use_backend apache if image
So, when I open my IP/images, it will trigger that and open Apache then, with port 8002.
For Apache, I created virtual hosts, and this is the "image" one:
<VirtualHost *:8002>
ServerAdmin my#email.com
ServerName image
ServerAlias image
DocumentRoot /srv/www/image/public_html/
ErrorLog /srv/www/image/logs/error.log
CustomLog /srv/www/image/logs/access.log combined
</VirtualHost>
So, that all works nicely, when I type IP/images it open the /srv/www/image/public_html. But then the issues come. As I am using the image uploading script, it involves a lot of rewriting, so I had to enable that mod. This is the .htaccess which is located in the public_html/images folder (I somehow had to make this subfolder too, to "match" the URL with the actual location in the public_html.
SetEnv PHP_VER 5_3
RewriteEngine On
# You must define your installation directory and uncomment the line :
RewriteBase /images/
RewriteRule ^([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=original&a=$1&e=$2 [L]
RewriteRule ^(icon|small|medium|square)\/([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=$1&a=$2&e=$3 [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) application.php?request=$1 [L,QSA]
So, basically, this is somethow not working. I suppose there is a conflict between this virtual host, subdirectory, rewriting or something, but I can't seem to isolate it.
It is a bit confusing that when I open the IP/images/xxxx.jpg it opens the image, which is located in the public_html/images/upload/original folder, so the rewrite is working. The the other rules seem not to be working. All of the thumbnails and smaller versions are not rendering properly (with the icon, small, medium, square), so that makes the site quite unsusable.
Here is the link of the development server: http://localhost/images/
Thanks in advance for your time and help!
The first thing you should do is determine whether mod_rewrite is in fact part of the problem by accessing one of the failing URLs directly via its rewritten form and verifying that you get the expected result.
Indeed, the problem might simply be that the PHP script for the smaller resolutions "doesn't work" while it does for the original size ones. The first of the following URLs nicely served me an image; the second one is supposed to give me a smaller version of the same image, but served me an HTTP 500:
http://106.186.21.176/images/controller/Resizer.php?m=original&a=q&e=png
http://106.186.21.176/images/controller/Resizer.php?m=small&a=q&e=png
I got the same result (HTTP 500) for any of the smaller-size format names mentioned in your post, which matches your problem description.
Once you've verified that the script works as expected, it's likely that the problem is with mod_rewrite. If so, enable rewrite logging: use the RewriteLog directive to activate it, and RewriteLogLevel to control its verbosity. Especially at the higher log levels, it can give you very detailed information about exactly what it's doing. This should make the problem readily apparent from the logs.
Also, if possible, try to avoid configuring mod_rewrite rules in .htaccess files -- move them into your main server config file instead. The reason is explained on Apache mod_rewrite Technical Details, section "API phases":
Unbelievably mod_rewrite provides URL manipulations in per-directory context, i.e., within .htaccess files, although these are reached a very long time after the URLs have been translated to filenames. It has to be this way because .htaccess files live in the filesystem, so processing has already reached this stage. In other words: According to the API phases at this time it is too late for any URL manipulations. To overcome this chicken and egg problem mod_rewrite uses a trick: When you manipulate a URL/filename in per-directory context mod_rewrite first rewrites the filename back to its corresponding URL (which is usually impossible, but see the RewriteBase directive below for the trick to achieve this) and then initiates a new internal sub-request with the new URL. This restarts processing of the API phases.
Again mod_rewrite tries hard to make this complicated step totally transparent to the user, but you should remember here: While URL manipulations in per-server context are really fast and efficient, per-directory rewrites are slow and inefficient due to this chicken and egg problem. But on the other hand this is the only way mod_rewrite can provide (locally restricted) URL manipulations to the average user.
In general, not using .htaccess at all has the added advantage that you can tell Apache to not even bother and disable the functionality all together, which save Apache from having to scan each directory level it serves from for the .htaccess files.

mod_rewrite to absolute path in .htaccess - turning up 404

I want to map a number of directories in a URL:
www.example.com/manual
www.example.com/login
to directories outside the web root.
My web root is
/www/htdocs/customername/site
the manual I want to redirect to is in
/www/customer/some_other_dir/manual
In mod_alias, this would be equal to
Alias /manual /www/customer/some_other_dir/manual
but as I have access only to .htaccess, I can't use Alias, so I have to use mod_rewrite.
What I have got right now after this question is the following:
RewriteRule ^manual(/(.*))?$ /www/htdocs/customername/manual/$2 [L]
this works in the sense that requests are recognized and redirected properly, but I get a 404 that looks like this (note the absolute path):
The requested URL /www/htdocs/customername/manual/resourcename.htm
was not found on this server.
However, I have checked with PHP: echo file_exists(...) and that file definitely exists.
why would this be? According to the mod_rewrite docs, this is possible, even in a .htaccess file. I understand that when doing mod_rewrite in .htaccess, there will be an automated prefix, but not to absolute paths, will it?
It shouldn't be a rights problem either: It's not in the web root, but within the FTP tree to which only one user, the main FTP account, has access.
I can change the web root in the control panel anytime, but I want this to work the way I described.
This is shared hosting, so I have no access to the error logs.
I just checked, this is not a wrongful 301 redirection, just an internal rewrite.
In .htaccess, you cannot rewrite to files outside the wwwroot.
You need to have a symbolic link within the webroot that points to the location of the manual.
Then in your .htaccess you need the line:
Options +SymLinksIfOwnerMatch
or maybe a little more blindly
Options +FollowSymlinks
Then you can
RewriteRule ^manual(/(.*))?$ /www/htdocs/customername/site/manual/$2 [L]
where manual under site is a link to /www/customer/some_other_dir/manual
You create the symlink on the command line with:
ln -s /www/htdocs/customername/site/manual /www/customer/some_other_dir/manual
But I imagine you're on shared hosting without shell access, so look into creating symbolic links within CPanel,Webmin, or whatever your admin interface is. There are php/cgi scripts that do it as well. Of course, you're still limited to the permissions that the host has given you. If they don't allow you to follow symlinks as a policy, you cannot override that within your .htaccess.
AFAIK mod_rewrite works at the 'protocol' level (meaning on the wire HTTP). So I suspect you are getting HTTP 302 with your directory path in the location.
So I'm afraid you might be stuck unless.. your hosting lets you follow symbolic links; so you can link to that location (assuming you have shell access or this is possible using FTP or your control panel) under your current document root.
Edit: It actually mentions URL-file phase hook in the docs so now I suspect the directory directives aren't allowing enough permissions.
This tells you what you need to know.
The requested URL /www/htdocs/customername/manual/resourcename.htm
was not found on this server.
It interprets RewriteRule ^manual(/(.*))?$ /www/htdocs/customername/manual/$2 [L] to mean rewrite example.com/manual/ as if it were example.com/www/htdocs/customername/manual/.
Try
RewriteRule ^manual(/(.*))?$ /customername/manual/$2 [L]
instead.