Servlets.Net is a premiere web site hosting and application hosting provider. We specialize in hosting web sites and web applications for Java Servlet developers. Our flexible services combine to provide a perfect fit for each customer. Building on a solid platform of system performance and stability, customer support, technical expertise and strong partner relationships, we offer the most sensible alternative for web site hosting. Learn why Servlets.net is the best choice for web developers, or sign up and find out for yourself!

Servlets.Net Corporation was established to serve the web application development community. Filling in a niche in the web services marketplace, Servlets.Net Corporation uses knowledge and experience gained from developing specific server-side Java solutions for various clients to produce a stable, affordable, high-performance platform for web applications developers.

Your Servlets.Net account is very flexible, allowing you to add multiple services of the same type to your account. Each of these services is allocated an area within your user area. The directory structure in your user area is designed to support the many services you can add to your account. Check out Account Configuration in Tutorial Section for more information.

Currently, you can modify certain basic settings for your account by using the Account Manager. You can get to the Account Manager by clicking on the YOUR ACCOUNT links located on every page of the Servlets.Net web site. Servlets.Net engineers are busy building a fully featured Account Management system that will replace the existing system. The new system will enable you to completely control all aspects of your account and services via your web browser. This includes adding new services, removing services, changing configuration settings, examine invoices online, and more.

In the meantime, please contact our Sales Department if you would like additional services to be added to your account or you need to make other modifications to your account.

Yes you do! Unlike many web hosting companies, all Virtual Servers hosted by Servlets.Net include their own private IP number to ensure compatibility with all web browsers. If we didn't have this policy, your Virtual server would have to rely on the HOST header that is sent from the browser to determine which site is being hit. This works for most current browsers, but is a problem for older browsers, robots, and other less common software.

Currently, Servlets.Net hosts all web sites using Apache-based web servers. High-performance hardware and UNIX based operating systems assure fast response time and infrequent downtime. Our network of speedy Red Hat Linux and Sun Solaris servers is located one hop away from all three major Internet backbone providers.

Currently we are only offering CGI support on an as needed basis. It does not come pre-installed with your Virtual Server. Servlets.Net is dedicated to promoting Java Servlet technologies, which provide a much better alternative to CGI. If you have a legacy application that requires CGI support, please contact our Sales Department.

Servlets.Net supports Authentication via .htaccess files. See the Dynaimc Configuration section of our FAQ.

Digital Certificates are available from a number of vendors, including Thawte and Verisign. Servlets.Net is a Thawte Consulting Hosting Partner, so we can walk you through the process of obtaining a certificate from them. VeriSign is another possible certificate vendor. We feel that Thawte currently has the best rates and customer service.

Access Reports for your site are generated using a program called wwwstat, unless you've selected the Advanced Reporting service for your site. These monthly reports are generated from the log files located in your user directory:

/home/<username>/logs/<sitename>/access*

The reports will be placed into an access_reports directory inside your web document root:

/home/<username>/www/<sitename>/access_reports

Since the reports are stored within your site's document root directory, you can view them with your web browser at:

http://www.yourserver.com/access_reports/

Servlets are programs written in Java that run in conjunction with a web server. Unlike previous attempts to provide the same sort of functionality (CGI, NSAPI, ISAPI, etc.) Java servlets run on most web servers with little or no modification. Since servlets are written in Java, they're generally easier to maintain than programs written in C or perl and are extremely portable between operating systems.

For more information on Java Servlets, look at the Java Servlet pages at Sun Microsystems.

More information can be found at Sun's JavaSoft web site. Many servlet examples come with JRunPro and have been installed onto your web server. We suggest exploring these examples as you familiarize yourself with servlets. The examples are located in this directory and its subdirectories:

/home//www//jrun

They can be viewed on your web site at this URL:

http://www.yourserver.com/jrun/index.html

Sun's sample servlets can be found in this location:

/usr/local/jrun/servlets

One of the best places to start learning about Servlets are the Java Servlet API pages at Sun Microsystems. Other great resources include Live Software's JRun Magazine, Oi Servlet World, and the Purple Technology Servlet FAQ.

This site has a newsletter that points out new articles and industry events as they occur -- check out ServletWatch!

The full list of servlets in the generic servlet library can be found in the Shared Servlet Library category of the Tutorials section. Usage information and source code is provided when available.

After extensive research, Servlets.Net established the Resin servlet engine as our new servlet engine of choice. All new Servlets.Net customers that select a Professional package will have Resin installed as the default servlet engine unless they request otherwise. Existing customers can upgrade their Professional package to Resin at no cost and with little or no disruption to their live applications.

Discover the many reasons to use Resin by clicking here. Resin is freely available for download and development purposes from: http://www.caucho.com/

The widely acclaimed JRun Pro product from Live Software is the servlet runner used for all older Servlets.Net hosted sites. We are currently using the 2.3.2 release of JRun Pro. Our relationship with Live Software assures rapid bug fixes and a solid product feedback loop.

Currently, all new accounts are installed with Sun's JDK 1.4. We have found it to be very fast and extremely stable - every page on the Servlets.Net website is generated on-the-fly by a servlet that combines content stored in a MySQL database into standard templates.

The Blackdown JDK 1.1.7, Blackdown 1.2, Sun's JDK 1.3 and Sun's JDK 1.2 are also available on Servlets.Net. More information is available at the Blackdown and Sun's websites.

We are also evaluating IBM's JDK and JIT. We have options for custom hosting on other platorms well. To learn about them, contact us at sales@servlets.net.

You might see performance improvements by using a Just-In-Time compiler with your servlet runner. To take advantage of the TYA JIT that is installed on each Servlets.Net server, you will need to run this command prior to starting your JRun Service Manager:

export JAVA_COMPILER=tya

If you want to always use the JIT, we suggest adding a JAVA_COMPILER=tya line to your .bash_profile file and adding JAVA_COMPILER to the end of the export line in that same file.

If you are using JDK1.2, the built-in JIT is automatically used. It can be disabled with a JAVA_COMPILER=NONE environment variable.

Java Connections determine how many simultaneous requests your servlet can handle. Our servlet runner (Caucho's Resin) exploits Java's multi-threaded nature to allow concurrent instances of a servlet to run without disturbing each other. Note that the number of Java Connections you have doesn't equal the number of simultaneous visitors your website may attract - most client requests take a few milliseconds to complete, so even one Java Connection can serve many site visitors.

JVM Memory provides the memory space in which your Java servlets run. See the JVM Memory service in Services for more information.

The JRun Administration Applet uses Swing components. Most current browsers do not natively support Swing components, but Swing support can be added quite easily. If you are getting an errror similar to "load: class com.livessoftware.jrunadmin.JRunAdminApplet not found" or the applet never seems to load, then you should make sure that your browser supports Swing.

(NOTE: This link is currently not working on the Sun site, but they say it will come back soon.) This article describes how to test your browser and how to upgrade your browser:
http://java.sun.com/products/jfc/tsc/web/applets/applets.html

You can install the Java 2 plug-in by going to this URL:
http://java.sun.com/products/plugin

Click here to test your Swing installation and make sure that it is properly installed. If the applet runs, you're set!

Alternatively, you can install the JRun Remote Admin Application.

Information about the number of requests your servlet engine is processing is logged once per hour to your stdout.log file. This file is located in this location:

/home/username/jrun/jsm-username-jsmname/logs/stdout.log

You can learn about what the information in these log entries means by reading this knowledge base article on Allaire's site: http://www.allaire.com/Handlers/index.cfm?ID=12435&Method=Full

Java Server Pages (JSP) is a scripting language that's a hybrid of Java and HTML. Much like Microsoft's ASP and Netscape's Server-Side JavaScript technologies, it allows web designers to embed scripting code in their HTML pages. When a JSP page is hit for the first time, it is pre-compiled into a Java file. This Java file is then automatically compiled into a Class file and placed in your servlets directory. Whenever you make changes to the JSP file, it is automatically recompiled.

More information can be found at Sun's JavaSoft web site. Many JSP examples come with Resin and JRun Pro and have been installed onto your web server. We suggest exploring these examples as you familiarize yourself with JSP. The examples are located in this directory:

/home//www//jrun/jsp

They can be viewed on your web site at this URL:

http://www.yourserver.com/jrun/jsp/index.html

We're currently running Resin-CMP 2.1.0, which supports versions 1.0, 1.1, and 1.2 of the Java Server Pages Specification. You can choose which version of JSP you would like to use. As new versions of JSP become available, we will make them available for Servlets.Net customers.

If you're a customer using JRun, you're using LiveSoft's version of JSP that comes with their JRun Pro 2.3.2 product. It includes two versions of JSP that comply with Sun's 0.92 and 1.0 Java Server Pages Specification. You can choose which version of JSP you would like to use.

If you're using JRun, your professional account allows you to use either JSP 0.92 or JSP 1.0. By default, your account is configured to run JSP 0.92. Here is information on how to switch between JSP versions.

Using the JRun Remote Admin applet or application, you will need to modify your Mapping Rules. This can also be done by editing your rules.properties file. It is located at:

/home/username/jrun/jsm-username-jsmname/services/jse/properties/rules.properties

If you want to use JSP 1.0, this mapping needs to be created:

*.jsp=com.livesoftware.jsp.JSPServlet

If you want to use JSP 0.92, this mapping should be used:

*.jsp=jsp

If you want to use both, you can choose a different file extension for one of them. For instance:

*.jsp92=jsp

Once the new mapping is made, you will need to restart your JRun Services Manager (JSM). Our JSM Control Tutorial shows how to restart your JSM.

Lastly, the Apache web server will need to be reloaded before any changes you make to your rules.properties file will be active. This is because Apache reads your rules.properties file at startup to determine what file extensions need to be passed to JRun. The Apache web server is automatically reloaded early in the morning every day, so your changes will be in effect the next day. They might actually be in effect earlier since Apache is periodically reloaded throughout the day by Servlets.Net staff.

You have a choice between the built-in Java compiler or Jikes. Your account comes pre-configured to use Jikes, which is installed at /usr/local/jdk/bin/jikes. We strongly recommend its use, since Jikes is a very fast compiler from IBM that strictly adheres to the Sun's Java specification. More information about Jikes can be found at IBM's AlphaWorks site

If you wish to use the built-in compiler, simply delete the line of text that refers to the Java Compiler on the Page Compilation panel in the JRun Pro administration utility.

If you have removed your Jikes setting and would like to use it again, the Java Compiler field of the Page Compilation panel should read:

/usr/local/jdk/bin/jikes -nowarn -classpath %c -d %d %f

If you are using JDK1.2, we recommend not using Jikes as it is not fully JDK1.2 compliant. Use the standard javac instead:

/usr/local/jdk1.2/bin/javac -nowarn -classpath %c -d %d %f

If you're using JRun, The JRunPro 2.3.1 release includes a utility called JSPC. The JSPC (JSP Compiler) is a java tool used to compile JSP pages to Java class files out of the context of a web server. This utility and more information is installed at this location:

/usr/local/jrun/contrib/jspc

Once you have pre-compiled your JSP files into Java files, you can then use Jikes or any other Java compiler to create Class files.

If you're using JRun, to get the JSP samples that demonstrate database use to function properly, you must first edit your dbsettings.jsp file. This file is located at:

/home//www//jrun/jsp/jspsamp/jspexamples/dbsettings.jsp

To meet your SQL Server needs, Servlets.Net offers a MySQL Database Service and a PostgreSQL Database Service.

MySQL, an ward-winning database by T.c.X. was included in the 1998 CNET Builder.com Product Awards as the Best Affordable Database. More information about MySQL is available at the MySQL website.

We also offer our customers PostgreSQL, which is the most advanced open-source database available. It is a sophisticated Object-Relational Database Management System (DBMS) that supports nearly all SQL constructs, including subselects, transactions, and user-defined types and functions. Excellent documentation exists for PostgreSQL You can read it by going to the following URL: http://www.postgresql.org/idocs/.

In addition, JRunPro comes with a pure Java SQL database called InstantDB. More information can be found in this directory:

/usr/local/jrun/instantdb

When you purchase one of our database services, JDBC drivers are automatically available to your Java Virtual Machine. The JDBC driver is the MM MySQL JDBC Driver by Mark Matthews. More information about this Type 4 JDBC driver is available at the mm.mysql website.

If you would like to use a different JDBC driver and you have a private JVM, you are welcome to install it into your user area.

There is a great ODBC driver available for Windows that lets you connect to your MySQL database from ODBC-enabled Windows programs such as Microsoft Access. Download links can be found in the MyODBC section of this page: http://www.mysql.com/download.html

A servlet, being a multithreaded application, may have several instances of itself running at the same time. When instances of the servlet try to share the same connection, they line up in a queue and wait for their turn. You'll get better performance if you have more than one database connection for them to share. There's a great way of efficiently using the database connections allotted to your account - a technique called database connection pooling.

Database connection pooling uses your database connections in an intelligent manner to help reduce the time a servlets waits for a database connection.

For Resin users, Resin comes with an excellent built-in connection pooling system. You can find out more about it by consulting the examples that were installed with your account.

For JRun Users, The DbConnectionBroker and JDBCGlobalBroker classes, available at Java Exchange, come pre-installed with your MySQL Database service. We've provided sample code to make your job even easier. We've also provide instructions on installing the PoolMan connection broker software that can be used from both JSP documents and servlets.

Here's what database connection broker software will supply to your database-intensive servlets:

Quicker connections. Normally, when a servlet requests a connection, the database server starts a new database thread, initializes it, then hands it to the servlet. This process takes time. A good database connection pooling system gets in between the servlet and the database engine. It holds a certain number of database connections open and just hands them to servlets as they need them. This is much faster than initializing database threads.

Intelligent connection use. As long as your servlet only needs a few database connections, the connection broker keeps a small number of connections open to streamline database and system memory use. When you request more connections, it dynamically adjusts its connection pool to provide your servlets with the connectivity they need.

We highly recommend using a global pool of database connections that is available to all of your servlets. Rather than having each servlet manage its own set of database connections, all of your servlets will access the same set of database connections. Sample code is available that demonstrates how to do this.

If you need a connection broker that can share database connections with both JSP documents and servlts, take a look at our PoolMan installation instructions.

You can change the password to access your MySQL database from the localhost (the command prompt on a Servlets.Net machine or from your servlets) by executing the following command from the command prompt:

mysqladmin -p password newpassword

To change your database password for remote access, you will need to install the MySQL clients for Windows. From your Windows-based machine, use this command:

mysqladmin -hwww.yourserver.com -uusername -p password newpassword

Keep these lines as shown, but replace newpassword with what you want your new password to be. Also replace www.yourserver.com with your web address and username with your database username. Do NOT type your current password where the word password is. The command must have the word password in it to indicate that you are changing a password.

When you press enter, you will be asked for your old password. Type it in and press enter. Your password will then be changed.

It is important to properly use database connection pooling when you are developing servlets that communicate with your database. There are only a certain number of database connections available to you, so pooling the connections efficiently is very important. More information on database connection pooling can be found in the Database section of the FAQ.

In the past, we've recommended using the Java Exchange pooling classes. There is nothing wrong with that package, but there is no built-in way to use it in JSP documents. We found that many customers were having trouble sharing the same pool of connections across both servlets and JSP documents with the Java Exchange solution.

Furthermore, we provided sample code for doing connection pooling within a JSP document using Allaire's JSPDBConnection bean. We've discovered that there are problems with Allaire's bean and do not recommend using it.

At this time, we've had good success using the Poolman connection pooling software. This software not only pools database connections, but it can also pool any sort of Java resource that you would like pooled. The package includes easy to use pooling mechanisms for using the same connection pool from both JSP and servlets. We've also found it to be very reliable.

An older version of Poolman is probably already installed with your Professional package. It is best to upgrade to the latest version. Below, we provide you with the steps necessary to install the latest version of PoolMan and get it up and running smoothly. As you review these instructions, if you find that your account does not include jrun/classes and jrun/lib directories, nor does it have a classpath.properties file, please let support@servlets.net know. We will upgrade your account to the latest configuration.

1. Log into your account via SSH or telnet. Make sure you are in your home directory:
   

   	cd /home/username

2. Download PoolMan 1.4 (or latest version)
   

   	lynx http://download.sourceforge.net/poolman/poolman-1.4.tar.gz

3. Install it into your home directory
   

   	tar xvzf poolman-1.4.tar.gz

4. Install the JAR file (overwrite the old version)
   

   	cp PoolMan-1.4/lib/PoolMan.jar jrun/lib

5. Install the poolman.props file into a directory in your classpath
   

   	cp PoolMan-1.4/lib/poolman.props jrun/classes

6. Copy the PoolMan.jsp sample to your web root
   

   	cp PoolMan-1.4/samples/PoolMan.jsp www/servername

7. Edit your poolman.props file to contain your database settings
   

   	vi jrun/classes/poolman.props

   You should only keep the sections that you can use. For instance, if you are using a MySQL database, get rid of the Oracle and Postgres sections. Here's an example of what it should look like. Make sure to set maximumsize to "2" so that you don't go over your maximum number of database connections. Put your password in place of the asterisks. You should also use your domain name, site alias, or IP number and the database name in the db_url.
   
   

   db_name.1=mySQL db_driver.1=org.gjt.mm.mysql.Driver db_url.1=jdbc:mysql://www.yourdomain.com/username_dbname db_username.1=username db_password.1=***** enableCache.1=true cacheSize.1=5 cacheRefresh.1=10000 connection_timeout.1=15000 checkfrequency.1=30000 usertimeout.1=10000 maximumsize.1=2

8. Download the JDBC 2.0 Optional Package from Sun that is required by PoolMan into your lib directory
   

   	cd jrun/lib
   	lynx http://java.sun.com/products/jdbc/download.html#binary

9. Install jdbc2_0-stdext.jar at the beginning of your classpath
   

   	cd ../jsm-username-jsmname/properties
   	vi classpath.properties

   Add /home/username/jrun/lib/jdbc2_0-stdext.jar to be beginning of you classpath, making sure to point at your home directory, not "username". It is absolutely critical that your classpath stay on one line. Do not introduce any line breaks into it or it will not work. Here's an example of classpath.properties:
   
   

   java.classpath=/home/username/jrun/lib/jdbc2_0-stdext.jar\:/home/username/jrun/lib /jsp.jar\:/home/username/jrun/lib/xml4j.jar\:/home/username/jrun/lib/xt.jar\:/home /username/jrun/lib/fesi.jar\:/home/username/jrun/lib/WebL.jar\:/home/username/jrun /lib/jrun.jar\:/home/username/jrun/lib/servlet.jar\:/home/username/jrun/lib/cfanyw here.jar\:/home/username/jrun/lib/NetComponents.jar\:/home/username/jrun/lib/OROMa tcher.jar\:/home/username/jrun/lib/jrunadmin.jar\:/home/username/jrun/classes\:/ho me/username/jrun/jsm-username-jsmname/classes\:/home/username/jrun/lib/mail.jar\:/ home/username/jrun/lib/activation.jar\:/home/username/jrun/lib/PoolMan.jar\:/home/ username/jrun/lib/mysql_both_comp.jar\:/home/username/jrun/lib/swing.jar\:/home/us ername/jrun/lib/instantdb.jar\:/usr/local/jdk1.2/jre/lib/rt.jar

10. Restart your JSM
    

    	cd ..
    	./stopjsm.sh
    	./startjsm.sh

11. Test your PoolMan.jsp page in a web browser
    

    	http://www.yourdoamin.com/PoolMan.jsp

    You will need to have created a table in your database before you can actually execute any meaningful commands. Assuming you have a table called "test" in your database, you could type in a command like this: "select * from test". Your data should be displayed.

That's it! Now you can review the code in PoolMan.jsp to help you get your own application going. There are other examples of using PoolMan and more information in the /home/username/PoolMan-1.4 directory. Feel free to remove that directory whenever you don't need it anymore. If you've followed these directions, the necessary jar and props files to make PoolMan work have been copied from that directory and are now installed in your jrun areas.

Best of luck getting your application up and running! Please let support@servlets.net know if you need further assistance.

Come back soon for answers to common Internet questions!

Using dynamic configuration files, you can add new MIME type mappings, add user- and host-based authentication to files and directories, alter the form of server-parsed HTML used on your server, configure the text of messages returned when your server encounters an error, control URL mappings with redirections, and customize HTTP response headers. All of these capabilities are discussed elsewhere in this document.

The Apache documentation does not discuss dynamic configuration files explicitly, but the documentation for each configuration directive specifies whether the directive can appear in a .htaccess file. Visit the Apache run-time configuration directives document and select Options. You'll see that .htaccess appears in the Context: header. This signifies that the Option directive can appear in .htaccess files.

User-based authentication

Adding user-based authentication involves two steps...

• Create a password file containing usernames and passwords
• Add appropriate directives to your dynamic configuration file (.htaccess)

Step 1: Create a password file containing usernames and passwords

The password file used in HTTP authentication is a text file containing pairs of usernames and encrypted passwords, one per line, separated by a colon. It is traditionally named htpasswd The following example illustrates the file format...

admin:oeoJB1X4JXF..
dirk:sOBLxYAjY2Ru2
pratt:Wd8LmSCg63yBE

Notice that the passwords are encrypted, not in plaintext. Passwords in HTTP authentication use the same format as those in the Unix system password file, which are encrypted with the crypt(3) C system call or an equivalent function provided by a language such as Perl. The crypt(3) C function uses the standard DES encryption algorithm to turn plaintext into ciphertext. The encrypted password is always 13 characters long (regardless of the length of your plaintext password) and may be composed of letters, numbers, `/', and '.'. The htpasswd command available on our servers can be used to create password files and add new users. Run it with no arguments from your developer shell account for a usage summary. Windows versions of htpasswd exist, but we have yet to find one whose encrypted passwords that work under Unix.

Here's an example of using the htpasswd command to create a password file in your developer account home directory and add a username...

[joeuser@s1 joeuser] htpasswd
Usage: htpasswd [-c] passwordfile username
The -c flag creates a new file.
[joeuser@s1 joeuser] htpasswd -c htpasswd admin
Adding password for admin.
New password:
Re-type new password:
[joeuser@s1 joeuser] htpasswd htpasswd dirk
Adding user dirk
New password:
Re-type new password:
[joeuser@s1 joeuser] cat htpasswd 
admin:q774.gXiXd.VU
dirk:iEHEDps1Wh8wM

To improve security, you should place your htpasswd file in a directory invisible to your HTTP server, such as your UNIX User home directory or a sibling of your document root directory. However, note that its permissions must allow world reads (but not world writes) because the HTTP server will open it as an unprivileged user. Use the chmod command to set file permissions.

Step 2: Add appropriate directives to your dynamic configuration file

Assume you wish to add user-based authentication to your server's access_reports file directory (a subdirectory of your HTTP server's document root directory named access_reports) and a file named credit-cards.txt in your document root directory. Also assume you wish to use a password file named htpasswd in your UNIX User home directory. The following directives would implement authentication when added to your .htaccess file...

<FILES access_reports>
require         valid-user
AuthType        Basic
AuthName        "Access Reports"
AuthUserFile    /home/joeuser/htpasswd
</FILES>

<FILES credit-cards.txt>
require         valid-user
AuthType        Basic
AuthName        "Credit card numbers"
AuthUserFile    /home/joeuser/htpasswd
</FILES>

These directives perform the following functions...

• The require directive specifies which usernames in the password file can access the protected resource. The valid-user parameter instructs the server to accept any valid username and password that appears in the password file. If you specify the user parameter followed by individual usernames (separated by a space), only those usernames will be able to access the protected resource.

• The AuthType directive specifies the type of authentication that will occur. Basic authentication is the only type which is widely implemented, but this directive exists to support future authentication methods, such as the more secure digest authentication.

• The AuthName specifies what is known as the authorization realm or realm string. This is the text displayed in the dialog box when your browser prompts you for a username and password. The authentication realm is also used by the browser to determine which username and password to send when multiple authenticated resources are accessed in the same browser session.

• The AuthUserFile directive specifies the path to the password file. This must be specified as an absolute path -- if specified as a relative path, the HTTP server will look in its root directory, which is not where your content resides.

The .htaccess file containing these directives would need to be placed in your document root directory because it refers to logs and credit-cards.txt with relative paths. You could place .htaccess in any server-visible directory if you specified the paths to the protected resources by absolute pathname (such as /home/joeuser/www/joeuser/credit-cards.txt).

Here are pointers to documentation on each of the directives used above...

• <Files>
• require
• AuthType
• AuthName
• AuthUserFile

Host-based authentication

Host-based authentication is configured similarly to user-based authentication. You can restrict access by host name (fully-qualified domain name or a subdomain) or IP address (a complete IP address or an IP network).

Assume you want to create an intranet on your Servlets.Net Web site in the subdirectory intranet. Also assume your organization's domain name is sample.org. You want all hosts in your domain to be able to access this resource, as well as all hosts in the IP network 192.168.1, which is outside your domain. You would do so with the following dynamic configuration file directives...

<FILES intranet>
order		deny, allow
deny		from all
allow		from sample.org 192.168.1
</FILES>

The deny and allow directives instruct the server about which hosts should be allowed to access the given resource.

Here are pointers to documentation on each of the directives used above...

• <Files>
• order
• deny
• allow