Re: a couple questions about virtual hosts in Apache

Tim,

NameVirtualHost *:80

<VirtualHost *:80>
ServerName pilotalk.com
ServerAlias pilotalk.com
UseCanonicalName On
ServerAdmin webmaster@xxxxxxxxxxxx
DocumentRoot /var/www/PilotalkBraillesoft.com
DirectoryIndex index.php
ErrorLog logs/PilotalkBraillesoft.com-error_log
CustomLog logs/PilotalkBraillesoft.com-access_log common
RewriteEngine On
RewriteCond %{HTTP_HOST} ^PILOTALK\COM$ [NC]
RewriteRule (.*)$ http://www.pilotalk.com/$1 [R=301,L]
</VirtualHost>


Scott

To: "For users of Fedora" <fedora-list@xxxxxxxxxx>
Sent: Friday, August 10, 2007 12:54 AM
Subject: Re: a couple questions about virtual hosts in Apache

On Thu, 2007-08-09 at 12:18 -0500, Scott wrote:

Tim,

You said:
found it best to have the default return nothing, and have virtual hosts
for anything that I specifically wanted.


What do you mean by this.  Are you saying to put hash marks in front of
certain things?  Can you please be more specific?

I put all my websites into virtual hosts, and left no files for the
default one to serve, except for an error message (the default 403
message that says Apache is installed).

i.e. The /var/www/html/ directory, where the default files are served
from is empty.

I don't put my virtual hosts as sub-directories inside there, as that
makes it too easy to grab files from another site.  I host them from a
different parent directory.

e.g. /var/www/site1/,  /var/www/site2/, and so on.

The ability for someone to browse to http://192.168.1.2/site1/ and grab
files they shouldn't, is one reason.  Access rules can sometimes be
worked around that way, if they're applied via URIs rather than
filepaths.

Another reason is that you can get people accessing your site through
more than one address, and that's a caching and bandwidth problem.  Some
will do it both ways, doubling the traffic, especially if search engines
pick you up both ways.

Also, because of the latter reason, I use URI rewriting rules on sites
that can be addressed in two ways.  For instance, if example.com can
also be reached at www.example.com, I'd put in a rule that caused
accesses for what I consider the wrong one to be rewritten to what I
consider the correct one.  The following three lines cause accesses to
example.com to become accesses to www.example.com:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

The second line matches host queries that "start" with example.com
(that's what the ^ carat in front of example means).  The [NC] means to
be non-case-sensitive.

Now anybody accessing the site gets corrected.  If they bookmark the
site, they should be bookmarking what I consider its address to be.
Likewise if they link to it.  Since it's done for them, people never
wonder whether they should be referring to the site with or without the
the www prefix.  They'll use the address that's currently showing in
their browser, the corrected one.

Putting that all together gives you something like:

<VirtualHost *:80>
 ServerName        www.example.com
 ServerAlias       example
 UseCanonicalName  On
 ServerAdmin       webmaster@xxxxxxxxxxx
 DocumentRoot      /var/www/example.com
 DirectoryIndex    homepage.html default.html index.html
 ErrorDocument     401  /responses/401.shtml
 ErrorDocument     403  /responses/403.shtml
 ErrorDocument     404  /responses/404.shtml
 ErrorLog          logs/example.com-error_log
 CustomLog         logs/example.com-access_log combined
 XBitHack          Full
 RewriteEngine     on
 RewriteCond       %{HTTP_HOST} ^example\.com$ [NC]
 RewriteRule       ^(.*)$ http://www.example.com/$1 [R=301,L]
</VirtualHost>

I also customise the server error pages to my site.  Though, if you're
not going to add information to them that's directly providing help for
them to use your site, I wouldn't bother.  The default ones are
multi-lingual.

--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386

Using FC 4, 5, 6 & 7, plus CentOS 5.  Today, it's FC7.

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.



--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list



--
No virus found in this incoming message.
Checked by AVG Free Edition.

Version: 7.5.476 / Virus Database: 269.11.11/944 - Release Date: 8/9/2007 2:44 PM