1.3.3- Managing Directories on your Web Server

<< 1.3.2- Testing your Web Server

Chapter1

1.4.0- Writing Our First ASP Example >>

Managing Directories on your Web Server

These days, many browsers are sufficiently advanced that you can use them to locate and examine files and pages that exist on your computer's hard disk. So, for example, you can start up your browser, type in the physical location of a web page (or other file) such as C:\My Documents\mywebpage.html, and the browser will display it. However, this isn't real web publishing at all:

 

• First, web pages are transported using a protocol called HTTP – the HyperText Transfer Protocol. Note that the http:// at the beginning of URL indicates that the request is being sent by HTTP. Requesting C:\My Documents\mywebpage.html in your browser doesn't use HTTP, and this means that the file is not delivered and handled in the way a web page should be. We'll discuss this in greater detail when we tackle HTTP at the start of Chapter 2.
• Second, consider the addressing situation. The string C:\My Documents\mywebpage.html tells us that the page exists in the \My Documents directory of the C: drive of the hard disk of the machine on which the browser is running. In a network situation, with two or more computers, this simply doesn't give enough information about the web server.

However, when a user browses (via HTTP) to a web page on some web server, the web server will need to work out where the file for that page is located on the server's hard disk. In fact, there's an important relationship between the information given in the URL, and the physical location (within the web server's file system) of the .htm or .asp file that contains the source for the page.

Virtual Directories

So how does this relationship work? In fact, it can work by creating a second directory structure on the web server machine, which reflects the structure of your web site. It sounds like it could be complicated, but it doesn't have to be. In fact, in this book it's going to be very simple.

 

The first directory structure is what we see when we open Windows Explorer on the web server – these directories are known as physical directories. For example, the folder C:\My Documents is a physical directory.

 

The second directory structure is the one that reflects the structure of the web site. This consists of a hierarchy of virtual directories. We use the web server to create virtual directories, and to set the relationship between the virtual directories and the real (physical) directories.

 

When you try to visualize a virtual directory, it's probably best not to think of it as a directory at all. Instead, just think of it as a nickname or alias for a physical directory that exists on the web server machine. The idea is that, when a user browses to a web page that is contained in the physical directory on the server, they don't use the name of the physical directory to get there: instead, they use the physical directory's nickname.

 

To see how this might be useful, consider a website that publishes news about many different sporting events. In order to organize his web files carefully, the webmaster has built a physical directory structure on his hard disk, which looks like this:

 

Now suppose you visit this web site to get the latest news on the Javelin event in the Olympics. If the URL for this web page were based on the physical directory structure, then the URL for this page would be something like this:

 

http://www.oursportsite.com/sportsnews/athletics/field/javelin/default.asp

 

That's OK for the webmaster, who understands his directory structure; but it's a fairly unmemorable web address! So, to make it easier for the user, the webmaster can assign a virtual directory name or alias to this directory – it acts just like a nickname for the directory. Here, let's suppose we've assigned the virtual name javelinnews to the c:\inetpub\...\javelin\ directory. Then the URL for the latest Javelin news is:

 

http://www.oursportsite.com/javelinnews/default.asp

 

By creating virtual directory names for all the directories (such as baseballnews, 100mnews, 200nnews, etc) it's easy for the user to type in the URL and go directly to the page they want:

 

http://www.oursportsite.com/baseballnews/default.asp

http://www.oursportsite.com/100mnews/default.asp

http://www.oursportsite.com/200mnews/default.asp

 

Not only does this save the user from long, unwieldy URLs – it also serves as a good security measure, because it hides the physical directory structure from all the web site visitors. Moreover, it allows the webmaster's web site structure to remain independent of the directory structure on his hard drive – so he can move files on his disk between different physical folders, drives, or even servers, without having to change the structure of his web pages.

 

Let's have a crack at setting up our own virtual directories and permissions (please note that these permissions are set automatically, if you use Visual Interdev or FrontPage to create a new site).

Let's take a quick look now at how you can create your own virtual directory. We'll use this directory to store the examples that we'll be creating in this book. We don't want to over-complicate this example by creating lots of directories, so we'll demonstrate by creating a single physical directory on the web server's hard disk, and using the IIS admin tool to create a virtual directory and make the relationship between the two.

 

1.    Start Windows Explorer and create a new physical directory named BegASPFiles, under the \Inetpub\wwwroot directory created by IIS on your hard drive.

 

 

2.    Next, start up the IIS admin tool (using the MMC, as we described earlier). Right-click on Default Web Site, and from the menu that appears select New | Virtual Directory. This starts the Virtual Directory Creation Wizard, which handles the creation of virtual directories for you and the setting up of permissions as well. You'll see the splash screen first, which looks like this. Click on Next.

 

3.    Type BegASP in the Alias text box; then click Next.

 

4.    Click on the Browse… button and select the directory \Inetpub\wwwroot\BegASPFiles that you created in Step 1. Then click Next.

 

5.    Make sure that the Read and Run scripts checkboxes are checked, and that the Execute checkbox is empty. Click on Next, and in the subsequent page click on Finish.

6.    The BegASP virtual directory will appear on the tree in the IIS admin window.

 

How It Works

You've just created a physical directory called BegASPFiles, in which we can store all of the examples for this book. You've also created a virtual directory called BegASP, which you created as an alias for the physical BegASPFiles directory. When we create examples later in this chapter, and throughout the book, we'll place the ASP files in the physical C:\Inetpub\wwwroot\BegASPFiles directory; and when we use the browser to test the pages, we'll use the URL http://my_server_name/BegASP/….

 

Note that the URL uses the alias /BegASP – IIS knows that this stands for the directory path C:\Inetpub\wwwroot\BegASPFiles. When executing ASP pages, you can reduce the amount of typing you need to do in the URL, by using virtual directory names in your URL in place of the physical directory names.

Permissions

As we've just seen, we can assign permissions to a new directory as we create it, by using the options offered in the Virtual Directory Wizard. Alternatively, we can set permissions at any time, from the IIS admin tool in the MMC. To do this, right-click on the BegASP virtual directory in the IIS admin tool, and select Properties. You'll get the following dialog:

 

 

It's quite a complicated dialog, and it contains a lot of options – not all of which we wish to go into now.

Creating an Application

If you look at the above screenshot, you will notice that we have created an application called BegASP – the same as our virtual directory. If the box next to the Application name label is blank, you need to hit the Create button, which is on the right of the box. After the application is created, this button becomes Remove. This will enable us to use Global.asa in our scripts – we will discuss Global.asa in Chapter 8.

 

Access Permissions

The four check boxes on the left are of interest to us, as they govern the types of access for the given directory and dictate the permissions allowed on the files contained within that directory. Let's have a look at what each of these options means:

• Scripts source access This permission enables users to access the source code of a script. It's only possible to allow this permission if the Read or Write permission has already been assigned. But we generally don't want our users to be able to view our ASP source code, so we would usually leave this checkbox unchecked for any directory that contains ASP scripts. By default, all directories created during setup have Scripts Source Access permission disabled.

• Read This permission enables browsers to read or download files stored in a home directory or a virtual directory. If the browser requests a file from a directory that doesn't have the Read permission enabled, then the web server will simply return an error message (such as the one shown below). Generally, directories containing information that you want to publish (such as HTML files, for example) should have the Read permission enabled.

 

Note that when the folder has Read permission turned off, HTML files within the folder cannot be read; but ASP scripts within the folder can still be run.

 

• Write If the write permission on a virtual directory is enabled, then users will be able to create or modify files within the directory, and change the properties of these files.

 

Directory Browsing If you want to allow people to view the contents of the directory (that is, to see a list of all the files that are contained in that directory), then you can allow this by checking the Directory Browsing option. Also, if someone tries to browse the contents of a directory that has Directory Browsing enabled but Read disabled, then they may receive the following message:

Execute Permissions

There's a text box near the foot of the Properties dialog, labeled Execute permissions – this specifies what level of program execution is permitted on pages contained in this directory. There are three possible values here – None, Scripts only, or Scripts and Executables:

 

• Setting Execute permissions to None means that users can only access static files, such as image files and HTML files. Any script-based files of other executables contained in this directory are inaccessible to users.
• Setting Execute permissions to Scripts Only means that users can also access any script-based pages, such as ASP pages. So if the user requests an ASP page that's contained in this directory, the web server will allow the ASP script to be executed, and for the resulting HTML to be sent to the browser.
• Setting Execute permissions to Scripts and Executables means that users can execute any type of file type that's contained in the directory. It's generally a good idea to avoid using this setting, in order to prohibit users from executing potentially damaging applications on your web server.

 

For any directory containing ASP files that you're publishing, the appropriate setting for the Execute permissions is Scripts Only.

 

<< 1.3.2- Testing your Web Server

Chapter1

1.4.0- Writing Our First ASP Example >>