Databases Reference
In-Depth Information
include "/home/ohs/OraHome 1/ohs/conf/vhosts/*.conf"
This means I can create individual files in the
vhosts
subdirectory for each host I wish to support
which, for me at least, makes it much more manageable than having a single file that contains
everything. The
*.conf
in the
include
statement means include all files that have a file suffix of
conf
.
This, again, has a side benefit, which is that I can very easily disable a virtual host by renaming the
configuration file to
foo.conf.old
(or some other suffix) which means it won't be included when I reload
the OHS.
So now I can create a configuration file for my new virtual host—let's call it
foo-orders.conf
—which
contains the code in Listing 1-8.
Listing 1-8.
Example Virtual Hosts Configuration
<VirtualHost *:80>
ServerName www.foo-orders.com
ServerAlias www.foo-orders.com
DocumentRoot /home/foo/www/
ProxyPreserveHost On
RewriteEngine On
RewriteRule ^/$ /pls/apex/f?p=ORDERS:HOME:0: [R=301,L]
</VirtualHost>
Once again, much of this is specific to Apache rather than APEX, but I wanted to highlight how you
can configure the web server to give your end users a much more “friendly” URL. The key sections here
are the
ServerName
and
ServerAlias
sections which define that this virtual host is relevant for anyone
using
http://www.foo-orders.com
as the domain name part of the URL in their browser.
The
DocumentRoot
directive specifies which directory the static files (for example the JavaScript, CSS,
and images) will be served from. Recall earlier that I mentioned many people put these files below the
same directory the
/i/
directive points at. Well, using a virtual host like this lets you define different
directories for different applications, which makes it a much more flexible way to work. For example,
one huge benefit of this is that different developers can work on different applications and you can tie
the permissions down so that they can't overwrite each other's files.
The next important section is the
RewriteRule
directive itself. Apache rewrite rules are a language in
their own right and even have topics dedicated to them, so I don't intend to go into a huge amount of
detail on how they work, but as an overview the way to read them is as a regular expression and a result.
So in this example
RewriteRule ^/$ /pls/apex/f?p=ORDERS:HOME:0: [R=301,L]
the rewrite rule will fire if the incoming URL matches the regular expression
^/$
, where
^
means start
and
$
means end—in other words, if the entire URL is just
http://foo-orders.com/
, if it does match then
the user (or rather their browser) is redirected to the URL
/pls/apex/f?p=ORDERS:HOME:0:
, which is a
relative URL (relative to the same domain name). The
[R=301,L]
means that the web server returns an
HTTP-301 code to the browser, which tells the browser that this is a permanent redirect (as opposed to a
temporary one if your site is down for maintenance, for example).
Now, this virtual host example might look complex at first glance and, indeed, if you're unfamiliar
with Apache configuration (and rewrite rules) in general, it is a bit strange looking. However, you can
pretty much adopt a copy/paste approach to extend this example to support any URL, changing the
application and page alias (or id if you prefer). The one step I missed is obviously that you need to
