test

Sun Java System Web Server 6.1 SP12 Administrator's Guide

Chapter 16 Content Management

This chapter describes how you can configure and manage content for classes of virtual servers and virtual servers.

This chapter contains the following sections:

Setting the Primary Document Directory

The primary document directory (also called 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 class, specify a document directory with an absolute path. If you do not use a variable as part of that path, the document root for every virtual server in the class will default to the same directory. You can then change them individually in the Class Manager.

Another approach is to use a variable when you set the path for the class. For example, you can use the $id variable to create a directory named with the virtual server id for every virtual server in the class. You can set the class’ document root to be class_doc_root/$id. Using this path, if your class’ document directory is /sun/servers/docs/$id, the default document directory for a virtual server vs1 that belongs to the class is /sun/servers/docs/vs1.

For more information about the document directory and how it is used at the server instance, class, and virtual server level, see Document Root.

To change the primary document directory to use a different path or variable, perform the following steps.

ProcedureTo change the primary document directory

  1. From the Class Manager, click the Content Management tab.

  2. Click Primary Document Directory.

  3. Enter an absolute directory path or a variable, or a path and variable combination next to the virtual server.

    If you include the variable $id at the end of your document root absolute path, every virtual server by default, will have a default document root of class_doc_root/virtual_server_ID. For example, if your class’ document directory is /sun/servers/docs/$id, the default document directory for a virtual server vs1 that belongs to the class is /sun/servers/docs/vs1.

    For more information about variables, see Using Variables.

  4. Click OK.

    For more information, see the online help for the Primary Document Directory page.

    Note –

    Typically, each virtual server has its own primary document directory.

Setting Additional Document Directories

Most of the time, the documents for a virtual or server instance are in the primary document directory. Sometimes, 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.

If you set up an additional document directory without using variables, that directory will be set at the class level, and used by all virtual servers in the class.

If you want to set up additional document directories for individual virtual servers in the class, you must use variables so that the directory the URL prefix is mapped to is different for every virtual server.

ProcedureTo add an additional document directory

  1. From the Class Manager, click the Content Management tab.

  2. Click Additional Document Directories.

  3. Choose the URL prefix to map.

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

  4. Specify the directory to map those URLs to.

  5. Use an existing configuration style to specify how this directory should be configured.

  6. Click OK.

    For more information, see the online help for the Additional Document Directories page.

    By default, the server instance has several additional document directories. They have the following prefixes:

    • /manual

    • /servlet

    You should restrict access to these directories so that users cannot write to them. A sample ACL would be:

    deny (all) anyone;

    allow (rxli) all;

    allow (wd) privileged_user;

Customizing User Public Information Directories (UNIX/Linux)

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.

You can only set these for the entire class. There is no way to customize them on a per virtual server basis.

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 user's 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.

To configure your server to use public directories, follow these steps

ProcedureTo configure your server to use public directories

  1. From the Class Manager, click the Content Management tab.

  2. Click User Document Directories.

  3. Choose a user URL prefix.

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

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

    A typical directory is public_html.

  5. 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 are not needed are indicated with *):

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

  6. Choose whether to load the password database at startup.

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

  7. Choose whether to apply a configuration style.

  8. Click OK.

    For more information, see the online help for the User Document Directories page.

    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 Web 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 web server access log. No error will be logged to the errors 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 web server.

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.

Using Configuration Styles

You can apply a configuration style for the server to control access to directories from public information directories. This prevents users from creating symbolic links to information you do not want made public. For more information on configuration files, see Chapter 18, Applying Configuration Styles.

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 file obj.conf in the directory server_root/https-serve-id/config 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/Linux: You must have the correct permissions for your files or this function will not work. The document root user must be the same as the server user.

To enable remote file manipulation, follow these steps

ProcedureTo enable remote file manipulation

  1. From the Class Manager, click the Content Management tab.

  2. Click Remote File Manipulation.

  3. Choose to activate remote file manipulation.

  4. Click OK.

    For more information, see the online help for the Remote File Manipulation page.

Configuring Document Preferences

You use the Document Preferences page to set document preferences. This section discusses these topics:

These settings are all configured for the class, not individual virtual servers.

Setting the Document Preferences

To set the document preferences, follow these steps

ProcedureTo set the document preferences

  1. From the Class Manager, click the Content Management tab.

  2. Click Document Preferences.

  3. Choose the appropriate field values, as discussed in the following sections.

  4. Click OK.

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

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 the previous section, 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 CGI is activated.

If an index file is not found, the server generates an index file that lists all the files in the document root.

Caution – 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. Sometimes the server can not 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

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.

You can use variables to map directories to new directories. For example, you can map /new to /$docroot/new. The mapping will go to the document root for the virtual server.

For more information about variables, see Using Variables.

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 configure URL forwarding, follow these steps

ProcedureTo configure URL forwarding

  1. From the Class Manager, click the Content Management tab.

  2. Click URL Forwarding.

  3. Type the URL prefix you want to redirect, and whether you want to redirect it to another prefix or to a static URL.

  4. Click OK.

    For more information see the online help for the URL Forwarding page.

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 Class Manager.

To enable a customized error response, follow these steps

ProcedureTo enable a customized error response

  1. From the Class Manager, click the Content Management tab.

  2. Click Error Responses.

  3. Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.

  4. For each error code you want to change, specify the absolute path to the file or CGI that contains the error response.

  5. Click OK.

    For more information see the online help for the Error Responses page.

Changing the 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.

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

The following charset names recognized by Netscape Navigator 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 change the character set, perform the following steps.

ProcedureTo change the character set

  1. From the Class Manager, click the Content Management tab.

  2. Click International Characters.

  3. Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.

  4. Set the character set for all or part of the server.

    If you leave this field blank, the character set is set to NJava System.

  5. Click OK.

    For more information, see the online help for the International Characters page.

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 set the document footer, perform the following steps.

ProcedureTo set the document footer

  1. From the Class Manager, click the Content Management tab.

  2. Click Document Footer.

  3. Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific 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.

  4. Specify the type of files that you want to have include the footer.

  5. Specify the date format.

  6. 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:.

  7. Click OK.

    For more information see the online help for the Document Footer page.

Using htaccess

For information on using htaccess, see Using .htaccess Files.

Restricting Symbolic Links (UNIX/Linux)

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:

For more information about hard and symbolic links, see your UNIX/Linux 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 restrict symbolic links, perform the following steps.

ProcedureTo restrict symbolic links

  1. From the Class Manager, click the Content Management tab.

  2. Click Symbolic Links.

  3. Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.

  4. Choose whether to enable soft and/or hard links and the directory to start from.

  5. Click OK.

    For more information, see the online help for the Symbolic Links page.

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 parse HTML, perform the following steps.

ProcedureTo parse HTML

  1. From the Class Manager, click the Content Management tab.

  2. Click Parse HTML.

  3. Choose a resource for which the server will parse HTML.

    Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific 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.

  4. Choose whether to activate server-parsed HTML.

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

  5. 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/Linux, you can also choose to parse UNIX/Linux files with the execute permission turned on, though that can be unreliable.

  6. Click OK.

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

    For more information on using server-parsed HTML, see the Sun Java System Web Server 6.1 SP12 Programmer’s Guide.

Setting Cache Control Directives

Cache-control directives are a way for Sun Java System Web 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 set cache control directives, perform the following steps.

ProcedureTo set cache control directives

  1. From the Class Manager, click the Content Management tab.

  2. Click Cache Control Directives

  3. 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.

  4. Click OK.

    For more information see the online help for the Cache Control Directives page.

Using Stronger Ciphers

For information on setting stronger ciphers, see Setting Stronger Ciphers.

Configuring the Server for Content Compression

Sun Java System Web Server 6.1 supports HTTP content compression. Content compression allows you to increase delivery speed to clients and serve higher content volumes without increasing your hardware expenses. Content compression reduces content download time, a benefit most apparent to users of dialup and high-traffic connections.

With content compression, your Web server sends out compressed data and instructs the browser to decompress the data on the fly, thus reducing the amount of data sent and increasing page display speed.

You can configure your server in two ways to handle compressed data:

For information on enhancing the server’s compression-handling capabilities, see Compression-related Changes in obj.conf.

Configuring the Server to Serve Precompressed Content

You can configure Sun Java System Web Server to generate and store pre-compressed versions of files in a specified directory. When configured, and only if an Accept-encoding: gzip header is received, all requests for files from a directory configured to serve precompressed content are redirected to requests for an equivalent compressed file from that directory if such a file exists. For example, if the Web server receives a request for myfile.html, and both myfile.html and myfile.html.gz exist, then those requests with an appropriate Accept-encoding header receive the compressed file.

To configure your server to serve precompressed content, perform the following steps.

ProcedureTo configure your server to serve precompressed content

  1. From the Class Manager, click the Content Management tab.

  2. Click Serve Precompressed Content.

  3. Enter the following information:

    • Editing. Select the resource from where precompressed content will be served from the drop-down list. If you choose a directory, the server will serve precompressed content only when the server receives a URL for that directory or any file in that directory.

      Click the Browse button to browse the primary document directory, or click the Wildcard button to specify a wildcard pattern. For information on using wildcard patterns, see Wildcards Used in the Resource Picker.

      • Activate Serving Precompressed Content? Allows you to instruct the server to serve precompressed content for the selected resource.

      • Check Age. Specify whether to check if the compressed version is older than the non-compressed version. Possible values are yes and no.

        If set to yes, then the compressed version, if it is older than the non-compressed version, will not be selected.

        If set to no, then the compressed version, even if it is older than the non-compressed version, will always be selected.

        By default, the value is set to yes.

      • Vary Header. Specifies whether to use a Vary: Accept-encoding header. Select either yes or no.

        If set to yes, then a Vary: Accept-encoding header is always inserted when a compressed version of a file is selected.

        If set to no, then a Vary: Accept-encoding header is never inserted.

        By default, the value is set to yes.

  4. Click OK.

Configuring the Server to Compress Content on Demand

You can also configure the Sun Java System Web Server 6.1 to compresses transmission data on the fly. A dynamically generated HTML page doesn’t exist until a user asks for it. This is particularly useful for e-commerce-based Web applications and database-driven sites.

To configure your server to compress content on demand, perform the following steps.

ProcedureTo configure your server to compress content on demand

  1. From the Class Manager, click the Content Management tab.

  2. Click Compress Content on Demand.

  3. Enter the following information:

    • Editing. Select the resource from where compressed content will be served dynamically on demand from the drop-down list. If you choose a directory, the server will serve compressed content only when the server receives a URL for that directory or any file in that directory.

      Click the Browse button to browse the primary document directory, or click the Wildcard button to specify a wildcard pattern. For information on using wildcard patterns, see Wildcards Used in the Resource Picker.

      • Activate Compress Content on Demand? Choose whether the server should serve precompressed content for the selected resource.

      • Vary Header. Specify whether to insert a Vary: Accept-encoding header. Select either yes or no.

        If set to yes, then a Vary: Accept-encoding header is always inserted when a compressed version of a file is selected.

        If set to no, then a Vary: Accept-encoding header is never inserted.

        By default, the value is set to yes.

      • Fragment Size. Specifies the memory fragment size in bytes to be used by the compression library (zlib) to control how much to compress at a time. The default value is 8096.

      • Compression Level. Specifies the level of compression. Choose a value between 1 and 9. The value 1 yields the best speed; the value 9 the best compression. The default value is 6, a compromise between speed and compression.

  4. Click OK.

Compression-related Changes in obj.conf

When compression is enabled in the server, an entry gets added to the obj.conf file. A sample entry is shown below:

Output fn=”insert-filter” filter=”http-compression” type=”text/*”

To restrict compression to documents of a particular type only, or to exclude browsers that don’t work well with compressed content, you would need to edit the obj.conf file. For more information on what you need to do to accomplish this, see the Sun Java System Web Server 6.1 SP12 NSAPI Programmer’s Guide.