I do virtual servers so my layout may have additional depth to it that you 
don't need (and it doesn't directly answer your question but may give you some 
food for thought) but the folks up a Rochester pointed out that they liked it 
when I did a UCD session at the end of 1998 (brief pause while I pat myself on 
the back).

I start out with a web directory at the root of the root file system. You could 
call it something along the lines of webroot but the name is not that important.

Underneath that, I create a directory for each site. Again, name doesn't matter 
but I make them match the host name less the common part of the name. For 
example, if I have http://reallycoolsite.thomsonlearning.com, I'd have a 
directory called reallycoolsite under webroot.

Underneath each site directory, I create an images directory and directories 
for log analysis reports and a few other tools we give each site owner. This is 
typically as deep as I do directory structures but the people maintaining the 
content typically create individual directories for style sheets, javascripts, 
and any files included via SSI's.

Net.Data macros go in their own directory under the main directory (webroot). 
It's a bad idea to put the macros underneath the web root for each virtual site 
since someone could get the web server to dump out your raw macro if you forget 
to deny access to the directory.

I also create a directory for things common to all sites (corporate logos and 
stuff related to HTML versions of our invoices) and either create a global 
mapping in the server or symbolic links as needed.

Here's an example:

The directory structure ends up being:
 | |-css
 | |-images
 | |-includes
 | |-javascript

Your httpd.conf would have this in it:

<VirtualHost your.ip.address>
   ServerName reallycoolsite.somethin.com
   AlwaysDirectoryIndex On
   DirectoryIndex index.html
   DocumentRoot /websites/reallycoolsite
   UseCanonicalName Off
   HostNameLookups off
   IndexOrderDefault Ascending Name CaseSense
   <Directory /websites/reallycoolsite>
      order allow,deny          
      allow from all

which enables serving of anything under /websites/reallycoolsite.

I keep CGI programs in a library called CGIBIN. Here's the configuration I use 
for them and it's at the global level:
ScriptAlias /cgibin /qsys.lib/cgibin.lib
<Directory /qsys.lib/cgibin.lib>
   order allow,deny
   allow from all

Net.Data's also a CGI program but I want to refer to it as /db2www instead of 
/cgibin/db2www.pgm so I add the following at the global level:

ScriptAlias /db2www/ /qsys.lib/cgibin.lib/db2www.pgm/

The directory container I added above takes care of permissions.

To get access to /websites/common_images, you can either add a global mapping:

Alias /common_images /websites/common_images
<Directory /websites/common_images>
   order allow,deny          
   allow from all

or you can create a symbolic link:

ADDLNK OBJ('/websites/common_images') 
NEWLNK('/websites/reallycoolsite/common_images') LNKTYPE(*SYMBOLIC)

and then add Options +FollowSymLinks to your httpd.conf.

Finally, to turn on SSI's, add the following:

Options +Includes (note: you can just add +Includes to your existing options 
AddOutputFilter INCLUDES .shtml
AddOutputFilter INCLUDES .htm
AddOutputFilter INCLUDES .html
AddOutputFilter INCLUDES .pgm

This allows the server to parse both HTML pages and CGI programs (including 
Net.Data since it's runtime is also a .pgm type object) for SSI tags.

What this makes available is the following URL's:


When I need to refer to an image (or a CSS file, or anything else) from either 
a CGI program or a Net.Data macro, I also use an absolute path 
(/images/fred.jpg) so I don't have to worry about how many double dot's I need 
to make stuff work. If you don't use common templates for the pages, this isn't 
much of an issue but if you use the same templates at various levels within the 
site, it's just about impossible to use relative links. Also, it makes it 
easier for browser's to cache stuff which makes the page load quicker for your 
customers and reduce load on your server.

One situation I do have that's a slight twist on what you're doing is our B2B 
online store is shared by a bunch of virtual sites. In order to make it easier 
to track who's using the store in the log analysis reports, I've created 
various alias' to give each site it's own virtual directory.

Finally, I highly recommend that you take a look at the first few chapters of 
the book "Professional Apache 2.0". These chapters are introductory and covers 
a lot of this type of stuff. Besides that, the book is great for understanding 
how to configure an Apache based HTTP server.


-----Original Message-----
From: rick baird [mailto:rick.baird@xxxxxxxxx]
Sent: Tuesday, January 18, 2005 4:22 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] The proper way to set up your directory stucture for

I'm having a brain seizure, and i'm looking for some direction on the
'BEST' way of organizing web document directories.

I'm on V5R3, using apache for static pages and some homespun CGI (the
hard way) programs.

I want to begin using net.data and CGIDEV as well, and I'm having
difficulty deciding the proper way to set up my directory structure,
but before I do, I want to make sure I don't paint myself into a
corner by doing it wrong.

How do you all organize your directories?     by document type and
then application?  or by application and document type.  What about
images, static pages or net.data macros that could be used in several
different applications?

Mostly, I'm concerned about my html (static and generated) will be
able to easily 'find' my images, other pages, other links, etc.
without having to specify full path's to those objects, and to easily
navigate between static pages, cgi and net.data links.

for instance, can you think of anything functionally different between
the following:


and this:?



or some other way of organizing?

thanks in advance,

This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.