Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Administration Guide

> ## Chapter 16
> Managing Virtual Server Content

> This chapter describes how you can configure and manage the files served by virtual servers.

> This chapter includes the following topics:

> - Changing the Document Root
> - Setting Additional Document Directories
> - Enabling Remote File Manipulation
> - Using htaccess
> - Restricting Symbolic Links (UNIX)
> - Customizing User Public Information Directories (UNIX)
> - Setting the Document Preferences
> - Customizing Error Responses
> - Changing the International Character Set
> - Setting the Document Footer
> - Configuring URL Forwarding
> - Setting up Server-Parsed HTML
> - Setting Cache Control Directives
> - Using Stronger Ciphers

> ##

> Changing the Document Root

> The document root is the central directory where you store all the files you want to make available to remote clients.

> When you add a virtual server, you specify a document root with an absolute path. For more information about the document root and how it is used, see Document Root.

> To use the Administration interface to change the document root to use a different path:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the General Tab.
> 5. Enter an absolute directory path in the Document Root field.

> You need to create this directory manually.

> 6. Click OK.

> For more information, see the online help.

> Note | Typically, each virtual server has its own document root.

> ##

> Setting Additional Document Directories

> Most of the time, the documents for a virtual or server instance are in the document root. Sometimes, though, you may want to serve documents from a directory outside of the document root. You can do this by setting additional document directories. By serving from a document directory outside of the document root, you can let someone manage a group of documents without giving them access to your primary document root.

> To use the Administration interface to add an additional document directory:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Directories tab.
> 5. Click Additional Doc Directories.
> 6. Choose the URL prefix to map.

> Clients send this URL to the server when they want documents.

> 7. Specify the directory to map those URLs to.
> 8. Click OK.

> To for more information, see the online help.

> You should restrict access to additional document directories so that users cannot write to them.

> ##

> Enabling Remote File Manipulation

> When you enable remote file manipulation, clients are able to upload files, delete files, create directories, remove directories, list the contents of a directory, and rename files on your server. The virtual servers’ configuration file obj.conf contains the commands that are activated when you enable remote file manipulation. By activating these commands, you allow remote browsers to change a server’s documents. You should use access control to restrict write access to these resources to prevent unauthorized tampering.

> Note that enabling remote file manipulations should have no effect on using content management systems such as Microsoft Frontpage.

> UNIX: You must have the correct permissions for your files or this function will not work; that is, the document root user must be the same as the server user.

> To use the Administration interface to enable remote file manipulation:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Directories tab.
> 5. Click Remote File Manipulation.
> 6. Choose Entire Server from the resource picker to apply your change to the whole virtual server, or navigate to a specific directory within a virtual server.
> 7. Choose to activate remote file manipulation.
> 8. Click OK.

> For more information, see the online help.

> ##

> Using htaccess

> The htaccess files are dynamic configuration files that store a subset of configuration options. You can use htaccess files in combination with the Application Server standard access controls (standard access controls are always applied before any htaccess access controls).

> For information on using htaccess, see the Sun Java System Application Server Administrator’s Guide to Security.

> ##

> Restricting Symbolic Links (UNIX)

> You can limit the use of the file system links in your server. File system links are references to files stored in other directories or file systems. The reference makes the remote file as accessible as if it were in the current directory. There are two types of file system links:

> - Hard links—A hard link is really two filenames that point to the same set of data blocks; the original file and the link are identical. For this reason, hard links cannot be on different file systems.
> - Symbolic (soft) links—A symbolic link consists of two files, an original file that contains the data, and another that points to the original file. Symbolic links are more flexible than hard links. Symbolic links can be used across different file systems and can be linked to directories.

> For more information about hard and symbolic links, see your UNIX system documentation.

> File system links are an easy way to create pointers to documents outside of the primary document directory and anyone can create these links. For this reason you might be concerned that people might create pointers to sensitive files (for example, confidential documents or system password files).

> To use the Administration interface to restrict symbolic links:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Directories tab.
> 5. Click Symbolic Links.
> 6. Choose Entire Server from the resource picker to apply your change to the whole virtual server, or navigate to a specific directory within a virtual server.
> 7. Choose whether to enable soft and/or hard links and the directory to start from.
> 8. Click OK.

> For more information, see the online help.

> ##

> Customizing User Public Information Directories (UNIX)

> Sometimes users want to maintain their own web pages. You can configure public information directories that let all the users on a server create home pages and other documents without your intervention.

> With this system, clients can access your server with a certain URL that the server recognizes as a public information directory. For example, suppose you choose the prefix ~ and the directory public_html. If a request comes in for http://www.sun.com/~jdoe/aboutjane.html, the server recognizes that ~jdoe refers to a users’ public information directory. It looks up jdoe in the system’s user database and finds Jane’s home directory. The server then looks at ~/jdoe/public_html/aboutjane.html.

> This section contains the following topics:

> - Configuring Public Information Directories
> - Restricting Content Publication
> - Loading the Entire Password File on Startup

> ### Configuring Public Information Directories

> To use the Administration interface to configure your virtual server to use public directories:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Handling tab.
> 5. Click User Doc Directories.
> 6. Choose a user URL prefix.

> The usual prefix is ~ because the tilde character is the standard UNIX prefix for accessing a user’s home directory.

> 7. Choose the subdirectory in the user’s home directory where the server looks for HTML files.

> A typical directory is public_html.

> 8. Designate the password file.

> The server needs to know where to look for a file that lists users on your system. The server uses this file to determine valid user names and to find their home directories. If you use the system password file for this purpose, the server uses standard library calls to look up users. Alternatively, you can create another user file to look up users. You can specify that user file with an absolute path.

> Each line in the file should have this structure (the elements in the /etc/passwd file that aren’t needed are indicated with *):

> username:*:*:groupid:*:homedir:*

> 9. Choose whether to load the password database at startup.

> For more information, see Loading the Entire Password File on Startup.

> 10. Click OK.

> For more information, see the online help.

> Another way to give users separate directories is to create a URL mapping to a central directory that all of your users can modify.

> ### Restricting Content Publication

> In some situations a system administrator may want to restrict what user accounts are able to publish content via user document directories. To restrict a user’s publishing, add a trailing slash to the user’s home directory path in the /etc/passwd file:

> jdoe::1234:1234:John Doe:/home/jdoe:/bin/sh

> becomes:

> jdoe::1234:1234:John Doe:/home/jdoe/:/bin/sh

> After you make this modification, Sun Java System Application Server will not serve pages from this user’s directory. The browser requesting the URI receives a “404 File Not Found” error and a 404 error will be logged to the access log.

> If, at a later time, you decide to allow this user to publish content, remove the trailing slash from the /etc/passwd entry, then restart the Application Server Instance.

> ### Loading the Entire Password File on Startup

> You also have the option of loading the entire password file on startup. If you choose this option, the server loads the password file into memory when it starts, making user lookups much faster. If you have a very large password file, however, this option can use too much memory.

> ##

> Setting the Document Preferences

> This section contains the following topics:

> - Entering an Index Filename
> - Selecting Directory Indexing
> - Specifying a Server Home Page
> - Specifying a Default MIME Type

> To use the Administration interface to set the document preferences, follow these steps:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Handling tab.
> 5. Click Doc Preferences.
> 6. Choose the appropriate field values, as discussed in the following sections.
> 7. Click OK.

> The preferences you can set are discussed more fully in the sections that follow. For additional information, see the online help.

> ### Entering an Index Filename

> If a document name is not specified in the URL the server automatically displays the index file. The default index files are index.html and home.html. If more than one index file is specified, the server looks in the order in which the names appear in this field until one is found. For example, if your index filenames are index.html and home.html, the server looks for index.html and if it doesn’t find it looks for home.html.

> ### Selecting Directory Indexing

> A document directory will probably have several subdirectories. For example, there might be a directory called products, another called people, and so on. It’s often helpful to let clients access an overview (or index) of these directories.

> The server indexes directories by searching the directory for an index file called index.html or home.html, which is a file you create and maintain as an overview of the directory’s contents. For more information, see Entering an Index Filename. You can specify any file as an index file for a directory by naming it one of these default names, which means you can also use a CGI program as an index.

> If an index file isn’t found, the server generates an index file that lists all the files in the document root.

> Caution | If your server is outside the firewall, turn off directory indexing to ensure that your directory structure and filenames are not accessible.

> ### Specifying a Server Home Page

> When end users first access the server, the first file they see is usually called a home page. Usually, this file has general information about your server and links to other documents.

> By default, the server finds the index file specified in the Index Filename field in the Document Preferences page and uses that for the home page. However, you can also specify a file to use as the home page.

> ### Specifying a Default MIME Type

> When a document is sent to a client, the server includes a section that identifies the document’s type, so the client can present the document in the right way. However, sometimes the server can’t determine the proper type for the document because the document’s extension is not defined for the server. In those cases, a default value is sent.

> The default is usually text/plain, but you should set it to the type of file most commonly stored on your server. Some common MIME types include the following:

> text/plain | text/html
> text/richtext | image/tiff
> image/jpeg | image/gif
> application/x-tar | application/postscript
> application/x-gzip | audio/basic

> ##

> Customizing Error Responses

> You can specify a custom error response that sends a detailed message to clients when they encounter errors from your virtual server. You can specify a file to send or a CGI program to run.

> For example, you can change the way the server behaves when it gets an error for a specific directory. If a client tries to connect to a part of your server protected by access control, you might return an error file with information on how to get an account.

> Before you can enable a custom error response, you must create the HTML file to send or the CGI program to run in response to an error. After you do this, enable the response in the Administration interface.

> To use the Administration interface to enable a customized error response:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Handling tab.
> 5. Click Error Responses.
> 6. Choose Entire Server from the resource picker to apply your change to the whole virtual server, or navigate to a specific directory within a virtual server.
> 7. For each error code you want to change, specify the absolute path to the file or CGI that contains the error response.
> 8. Click OK.

> For more information see the online help.

> ##

> Changing the International Character Set

> The character set of a document is determined in part by the language it is written in. You can override a client’s default character set setting for a document, a set of documents, or a directory by selecting a resource and entering a character set for that resource.

> Browsers can use the MIME type charset parameter in HTTP to change its character set. If the server includes this parameter in its response, the browser changes its character set accordingly. Examples are:

> - Content-Type: text/html;charset=iso-8859-1
> - Content-Type: text/html;charset=iso-2022-jp

> The following charset names are specified in RFC 1700 (except for the names that begin with x-):

> us-ascii | iso-8859-1
> iso-2022-jp | x-sjis
> x-euc-jp | x-mac-roman

> Additionally, the following aliases are recognized for us-ascii:

> ansi_x3.4-1968 | iso-ir-6
> ansi_x3.4-1986 | iso_646.irv:1991
> ascii | iso646-us
> us | ibm367
> cp367 |

> The following aliases are recognized for iso_8859-1:

> latin1 | iso_8859-1
> iso_8859-1:1987 | iso-ir-100
> ibm819 | cp819

> To use the Administration interface to change the character set:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Handling tab.
> 5. Click International Characters.
> 6. Choose Entire Server from the resource picker to apply your change to the whole virtual server, or navigate to a specific directory within a virtual server.
> 7. Set the character set for all or part of the server.

> If you leave this field blank, the character set is set to NONE.

> 8. Click OK.

> For more information, see the online help.

> ##

> Setting the Document Footer

> You can specify a document footer, which can include the last-modified time, for all the documents in a certain section of the server. This footer works for all files except output of CGI scripts or parsed HTML (.shtml) files. If you need your document footer to appear on CGI-script output or parsed HTML files, enter your footer text into a separate file and add a line of code or another server-side include to append that file to the page's output.

> To use the Administration interface to set the document footer, follow these steps:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the Doc Handling tab.
> 5. Click Doc Footer.
> 6. Choose Entire Server from the resource picker to apply your change to the whole virtual server, or navigate to a specific directory within a virtual server.

> If you choose a directory, the document footer applies only when the server receives a URL for that directory or any file in that directory.

> 7. Specify the type of files that you want to have include the footer.
> 8. Specify the date format.
> 9. Type any text you want to have appear in the footer.

> The maximum number of characters for a document footer is 765. If you want to include the date the document was last modified, type the string :LASTMOD:.

> For more information see the online help.

> ##

> Configuring URL Forwarding

> URL forwarding allows you to redirect document requests to another server. Forwarding URLs or redirection is a method for the server to tell a user that a URL has changed (for example, because you have moved files to another directory or server). You can also use redirection to seamlessly send a person who requests a document on one server to a document on another server.

> For example, if you forward http://www.sun.com/info/movies to a prefix film.sun.com, the URL http://www.sun.com/info/movies redirects to http://film.sun.com/info/movies.

> Sometimes you may want to redirect requests for all the documents in one sub-directory to a specific URL. For example, if you had to remove a directory because it was causing too much traffic, or because the documents were no longer to be served for any reason, you could direct a request for any one the documents to a page explaining why the documents were no longer available. For example, a prefix on /info/movies could be redirected to http://www.sun.com/explain.html.

> To use the Administration interface to configure URL forwarding:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the HTTP/HTML tab.
> 5. Click URL Forwarding.
> 6. Type the URL prefix you want to redirect, and whether you want to redirect it to another prefix or to a static URL.
> 7. Click OK.

> For more information see the online help.

> ##

> Setting up Server-Parsed HTML

> HTML is normally sent to the client exactly as it exists on disk without any server intervention. However, the server can search HTML files for special commands (that is, it can parse the HTML) before sending documents. If you want the server to parse these files and insert request-specific information or files into documents, you must first enable HTML parsing.

> To use the Administration interface to set up HTML parsing:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the HTTP/HTML tab.
> 5. Click Parse HTML.
> 6. Choose Entire Server from the resource picker to apply your change to the whole virtual server, or navigate to a specific directory within a virtual server.

> If you choose a directory, the server will parse HTML only when the server receives a URL for that directory or any file in that directory.

> 7. Choose whether to activate server-parsed HTML.

> You can activate for HTML file s but not the exec tag, or for HTML files and the exec tag, which allows HTML files to execute other programs on the server.

> 8. Choose which files to parse.

> You can choose whether to parse only files with the .shtml extension, or all HTML files, which slows performance. If you are using UNIX, you can also choose to parse UNIX files with the execute permission turned on, though that can be unreliable.

> 9. Click OK.

> For more information on setting your server to accept parsed HTML, see the online help.

> For more information on using server-parsed HTML, see the Sun Java System Application Server Developer’s Guide to Web Applications.

> ##

> Setting Cache Control Directives

> Cache-control directives are a way for Sun Java System Application Server to control what information is cached by a proxy server. Using cache-control directives, you override the default caching of the proxy to protect sensitive information from being cached, and perhaps retrieved later. For these directives to work, the proxy server must comply with HTTP 1.1.

> For more information HTTP 1.1, see the Hypertext Transfer Protocol--HTTP/1.1 specification (RFC 2068) at:

> http://www.ietf.org/

> To use the Administration interface to set cache control directives:

> 1. In the left pane, for the application server instance, open HTTP Server.
> 2. Open Virtual Servers.
> 3. Click the name of the virtual server you want to edit.
> 4. Click the HTTP/HTML tab.
> 5. Click Cache Control Directives
> 6. Fill in the fields. Valid values for the response directives are as follows:
> - Public. The response is cachable by any cache. This is the default.
> - Private. The response is only cachable by a private (non-shared) cache.
> - No Cache. The response must not be cached anywhere.
> - No Store. The cache must not store the request or response anywhere in nonvolatile storage.
> - Must Revalidate. The cache entry must be revalidated from the originating server.
> - Maximum Age (sec). The client does not accept a response that has an age greater than this age.
> 7. Click OK.

> For more information see the online help.

> ##

> Using Stronger Ciphers

> For information on setting stronger ciphers, see the Sun Java System Application Server Administrator’s Guide to Security.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.