Sun Java System Web Server 7.0 Administrator's Guide

Chapter 9 Managing Server Content

This chapter describes how you can configure and manage content across virtual servers.

Configuring Document Directories

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.

You can create a document directory, which is in addition to the primary document directory. By doing this, you can let someone manage a group of documents without giving them access to your primary document root.

ProcedureTo Create a Document Directory

  1. Select the Configuration.

    Select the configuration from the configurations list. Click Configurations tab to get the available configurations.

  2. Select the Virtual Server.

    Select the virtual server for which you need to add a new document directory. Click Virtual Servers tab to get the list of configured virtual servers for the selected configuration.

  3. Click Content Handling > Document Directories tab.

  4. Click New button. Configure the following parameters:

    • URL Prefix — URI prefix that has to be mapped to a directory.

    • Directory Path — Absolute server path and a valid directory for storing documents.


    Note –

    Using CLI

    For creating a document directory through CLI, execute the following command.


    wadm> create-document-dir --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 --vs=config1_vs_1 
    --uri-prefix=/config1_uri --directory=../docs1

    See CLI Reference, create-document-dir(1).


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

ProcedureTo Change the Default MIME Type

  1. Select the Configuration.

    Select the configuration from the configurations list. Click Configurations tab to get the available configurations.

  2. Select the Virtual Server.

    Click Virtual Servers tab to get the list of configured virtual servers for the selected configuration.

  3. Click Content Handling > General tab.

  4. Change Default MIME Type value under Miscellaneous section


    Note –

    Using CLI

    For creating a MIME type through CLI, execute the following command.


    wadm> create-mime-type --user=admin --password-file=admin.pwd --host=serverhost 
    --port=8989 --config=config1 --extensions=sxc application/sxc

    See CLI Reference, create-mime-type(1).

    You need not create a separate MIME types file for each virtual server. Instead, you can create as many MIME types files as you require and associate them with a virtual server. By default, one MIME types file (mime.types) exists on the server and cannot be deleted.


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.

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.

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

ProcedureConfiguring Document Directories

  1. From the virtual server page, click the Content Handling tab.

  2. Click Document Directories.

  3. Under User Document Directories, 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 aren’t needed are indicated with *):

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

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

  7. Click Save.

    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.

Setting up URL Redirection

URL redirection allows you to redirect document requests for one HTTP URL to another HTTP URL. 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 request for 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 can 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 can be redirected to http://www.sun.com/explain.html.

You can set URL redirection at the virtual server level.

To configure URL redirection, perform the following steps:

  1. Click Configurations tab and select the configuration from the configuration list.

  2. Click Virtual Servers sub tab and select the virtual server from the virtual server list.

  3. Click on Content Handling sub tab and URL Redirects sub tab.

  4. Click on New button to add a new URL redirect rule.

  5. Provide necessary values for fields described in . Click on Ok button. You may need to click on Deploy button for the configuration if needed.

The following table describes the parameters required while adding a new URL Redirect rule.

Table 9–1 URL redirect Parameters

Parameter

Description

From URL

URL from which the requests should be redirected. All HTTP requests to this URL will be redirected to the URL specified in the Target URL. 

Target URL

URL to which the requests should be redirected. All HTTP requests from the URL specified in the From URL will be redirected to this URL. 

URL Type

Fixed. Enabled/Disabled. Fixed URLs are static URLs like a link to an HTML page. Non-Fixed URLs are dynamic URLs with request parameters or URLs with just prefixes.


Note –

Using CLI

For adding a new URL redirection rule through CLI, execute the following command.


wadm> create-url-redirect --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --no-ssl --config=config1 --vs=config1_vs_1 --uri-prefix=/redirect 
--target-url=http://www.cnet.com

See CLI Reference, create-url-redirect(1).


URL Redirection Using Regular Expression

Sun Java System Web Server 7.0 is enhanced to support regular expressions (also known as Patterns) and request time parameter interpolation in configuration files. In addition, wildcard pattern matching support is extended to server.xml. URL redirecting is implemented as a SAF. The redirect SAF lets you redirect URIs that match a certain prefix. You can specify the prefix using the from parameter and the URL to redirect to using the url or url-prefix parameters. In Sun Java System Web Server 7.0, the from parameter is optional. If from is omitted, all URIs are redirected.

In the obj.conf file, SAF parameters are supported with new <If>, <Elseif> and <Else> tags. See, Appendix - obj.conf - Syntax and Usage. These tags contain directives. Using these tags, you can define conditions under which the directives are executed. These tags can also be used to dynamically generate SAF parameters.

Sun Java System Web Server 7.0 offers URL rewrite capability that is a super set of Apache HTTP server's mod_rewrite module. Unlike Apache's mod_rewrite function, <If> tag provides the following functionality:

Consider the following directive:


NameTrans fn="redirect"
          	      from="/site1"
                 url="http://site1.mycompany.com"

The above directive can be rewritten using regular expression as follows:


<If $uri =~ '^/site1'>
           NameTrans fn="redirect"
           url="http://site1.mycompany.com"
</If>

In the above snippet, note the usage of regular expression instead of the from parameter. If you need to redirect all requests for /site1/* to http://site1.mycompany.com/*/index.html note this technique:


<If $uri =~ '^/site1/(.*)'>
           NameTrans fn="redirect"
           url="http://site1.mycompany.com/$1/index.html"
</If>

Here, the <If> tag assigns whatever value matches (.*) to the variable $1. The $1 in the url parameter is dynamically replaced with the value from the original request. That means the above obj.conf snippet will cause a request for /site1/download to be redirected to http://site1.mycompany.com.com/download/index.html.

Combination of <If> and redirect offers some of the flexibility of mod_rewrite. However, unlike mod_rewrite, <If> can be used for things other than redirecting and rewriting URLs. <If> can also be used in conjunction with any SAF, including third party plug-ins.

The above method configures a 302 Moved Temporarily redirect. In Sun Java System Web Server 7.0, you can also add a status="301" parameter to indicate that you need a 301 Moved Permanently redirect instead


NameTrans fn="redirect" from="/path" url="http://server.example.com" status="301"

Overview of CGI

Common Gateway Interface (CGI) programs can be defined with any number of programming languages. On a UNIX/Linux machine, you’re likely to find CGI programs written as Bourne shell or Perl scripts.


Note –

Under UNIX/Linux, there are extra CGIStub processes running that the server uses to aid in CGI execution. These processes are created only during the first access to a CGI. Their number varies depending upon the CGI load on the server. Do not kill these CGIStub processes. They disappear when the server is stopped.


For more information see the discussion regarding MinCGIStub, MaxCGIStub, and CGIStubIdleTimeout in the online Sun Java System Web Server Performance Tuning and Sizing Guide.

On a Windows computer, you might find CGI programs written in C++ or batch files. For Windows, CGI programs written in a Windows-based programming language such as Visual Basic use a different mechanism to operate with the server. They are called Windows CGI programs.


Note –

In order to run the command-line utilities, you need to manually set the Path variable to include server_root/bin/https/bin.


Regardless of the programming language, all CGI programs accept and return data in the same manner. For information about writing CGI programs, see the following sources of information:

The following figure describes how CGI request is processed in Web Server 7.0:

Sun Java System Web Server 7.0

There are two ways to store CGI programs on your server machine:

You can enable both options at the same time if desired.

There are benefits to either implementation. If you want to allow only a specific set of users to add CGI programs, keep the CGI programs in specified directories and restrict access to those directories. If you want to allow anyone who can add HTML files to be able to add CGI programs, use the file type alternative. Users can keep their CGI files in the same directories as their HTML files.

If you choose the directory option, your server attempts to interpret any file in that directory as a CGI program. By the same token, if you choose the file type option, your server attempts to process any files with the file extensions .cgi, .exe, or .bat as CGI programs. If a file has one of these extensions but is not a CGI program, an error occurs when a user attempts to access it.


Note –

By default, the file extensions for CGI programs are .cgi, .exe and .bat. However, you can change which extensions indicate CGI programs by modifying the MIME types file. You can do this by choosing the Server Preferences tab and clicking the MIME Types link.


Configuring CGI Subsystem for Your Server

Sun Java System Web Server allows you to add CGI document directories using the administration console GUI.

To add a new CGI document directory, perform the following tasks:

  1. Click Configurations tab and select the configuration from the configuration list.

  2. Click Virtual Servers sub tab and select the virtual server from the virtual server list.

  3. Click Content Handling sub tab and CGI sub tab.

  4. Click New button to add a new CGI document directory.

  5. Provide necessary values for fields described in . Click on OK button. You may need to click on Deploy button for the configuration if needed.

The following table describes the fields required while adding a new CGI document directory.

Table 9–2 CGI Parameters

Parameter

Description

Prefix 

Type the URL prefix to use for this directory. That is, the text you type appears as the directory for the CGI programs in URLs.  

For example, if you type cgi-bin as the URL prefix, then all URLs to these CGI programs have the following structure:

http://yourserver.domain.com/cgi-bin/program-name

CGI Directory 

In the CGI Directory text field, type the location of the directory as an absolute path. Note that this directory doesn’t have to be under your document root. This is the reason that you need to specify a URL prefix. 


Note –

The URL prefix you specify can be different from the real CGI directory.


User 

Specify the name of the user to execute CGI programs as. 

Group 

Specify the name of the group to execute the CGI programs as. 

Chroot 

Specify the directory to chroot to before execution begins. 

Nice 

Specify a nice value, an increment that determines the CGI program's priority relative to the server. 

Typically, the server is run with a nice value of 0 and the nice increment would be between 0 (the CGI program runs at same priority as server) and 19 (the CGI program runs at much lower priority than server). While it is possible to increase the priority of the CGI program above that of the server by specifying a nice increment of -1, this is not recommended. 

To remove an existing CGI directory, select the CGI directory and click Delete button. To change the URL prefix or CGI directory of an existing directory, click on the directory link.

Copy your CGI programs into the directories you’ve specified. Remember that any files in those directories will be processed as CGI files, so do not put HTML files in your CGI directory.

For specifying CGI as a file type, perform the following tasks:

  1. Click Configurations tab and select the configuration from the configuration list.

  2. Click Virtual Servers sub tab and select the virtual server from the virtual server list.

  3. Click Content Handling sub tab and CGI sub tab.

  4. Click CGI as file type radio box enable.

The CGI files must have the file extensions .bat, .exe, or .cgi. Any non-CGI files with those extensions are processed by your server as CGI files, causing errors.


Note –

Using CLI

You can create a CGI directory that contains the CGI programs that will be processed by your server. CGI programs are in a certain file type such as .cgi, .exe, or .bat. The programs can be located in any directory in or under the document root directory.

To add a CGI directory through CLI execute the following command.


wadm> create-cgi-dir --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --config=config1 --vs=config1_vs_1 --uri-prefix=/config1_urlprefix 
--directory=/cgi-dir

See CLI Reference, create-cgi-dir(1).


Downloading Executable Files

If you’re using .exe as a CGI file type, you cannot download .exe files as executable files.

One solution to this problem is to compress the executable files that you want users to be able to download, so that the extension is not .exe. This solution has the added benefit of making the download time shorter.

Another possible solution is to remove .exe as a file extension from the magnus-internal/cgi type and add it instead to the application/octet-stream type (the MIME type for normal downloadable files). You can do this through the Server Manager, by choosing the Server Preferences tab and clicking the MIME Types link. However, the disadvantage to this method is that after making this change you cannot use .exe files as CGI programs.

Another solution is to edit your server’s obj.conf file to set up a download directory, where any file in the directory is downloaded automatically. The rest of the server won’t be affected. For more information, see:

http://developer.netscape.com/docs/manuals/enterprise/admnunix/programs.htm

Installing Shell CGI Programs for Windows

Overview of Shell CGI Programs for Windows

Shell CGI is a server configuration that lets you run CGI applications using the file associations set in Windows.

For example, if the server gets a request for a shell CGI file called hello.pl, the server uses the Windows file associations to run the file using the program associated with the .pl extension. If the .pl extension is associated with the program C:\\bin\\perl.exe, the server attempts to execute the hello.pl file as follows:

c:\\bin\\perl.exe hello.pl

The easiest way to configure shell CGI is to create a directory in your server’s document root that contains only shell CGI files. However, you can also configure the server to associate specific file extensions with shell CGI by editing MIME types from the Sun ONE Web Server.


Note –

For information on setting Windows file extensions, see your Windows documentation.


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.

To add a custom error page, follow these steps:

  1. Click Configurations tab and select the configuration from the configuration list.

  2. Click Virtual Servers sub tab and select the virtual server from the virtual server list.

  3. Click Content Handling sub tab and Error Pages sub tab.

  4. Click New button to add a custom error page.

    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 to return to the error pages list.


Note –

Using CLI

For customizing error pages through CLI, execute the following command.


wadm> set-error-page --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --config=config1 --vs=config1_vs_1 --code=500 
--error-page=/server-error-uri-new 

See CLI Reference, set-error-page(1).


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.

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

The following charset names recognized by some common browsers are specified in RFC 17.000 (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.0

  • cp367.0

 

The following aliases are recognized for iso_8859-1:

  • latin1

  • iso_8859-1

  • iso_8859-1:1987.0

  • iso-ir-100

  • ibm819

  • cp819

To change the character set, follow these steps:

ProcedureChanging Character Set

  1. From the Virtual Server page, click the Content Handling tab.

  2. Click the General tab.

  3. Set the default character set under the Miscellaneous section.

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

  4. Click Save.

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, follow these steps:

ProcedureTo Set the Document Footer

  1. From the virtual server page, click the Content Handling tab.

  2. Click General sub tab and go to Document Footer section.

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

  4. Specify the date format.

  5. Type any text you want to have appear in the footer.

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

  6. Click Save.


    Note –

    Using CLI

    For setting the document footer through CLI, execute the following command.


    wadm> enable-document-footer --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 --vs=config1_vs_1 
    --mime-type=text/html --date-format=%B --footer="config1 footer"

    See CLI Reference, enable-document-footer(1).


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, follow these steps:

ProcedureTo Restrict Symbolic Links

  1. From the virtual server page, click the Content Handling tab.

  2. Click General sub tab.

  3. Go to Symbolic Links section under Miscellaneous section.

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

  5. Click Save


    Note –

    Using CLI

    For restricting symbolic links through CLI, execute the following command.


    wadm> set-symlinks-prop --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 --vs=config1_vs_1 
    allow-soft-links=true allow-hard-links=false directory=/abc

    See CLI Reference, set-symlinks-prop(1).


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, follow these steps:

ProcedureTo Set Server Parsed HTML

  1. From the virtual server page, click the Content Handling tab.

  2. Click General sub tab.

  3. Under Parsed HTML/SSI Settings, 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.

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

  5. Click Save.

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


    Note –

    Using CLI

    For setting up server parsed HTML through CLI, execute the following command.


    wadm> enable-parsed-html --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 --vs=config1_vs1

    See CLI Reference, enable-parsed-html(1).


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, follow these steps:

ProcedureTo Set Cache Control Directives

  1. From the virtual server page, click the Content Handling tab.

  2. Click General sub tab and go to Cache Control Directives field under Miscellaneous section.

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


    Note –

    Using CLI

    For setting cache control directives through CLI, execute the following command.


    wadm> set-cache-control-directives --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=config1 --vs=config1_vs_1 public=true 
    private=true must-revalidate=true

    See CLI Reference, set-cache-control-directives(1).


Configuring the Server for Content Compression

Sun Java System Web Server 7.0 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.

Configuring the Server to Serve Pre-compressed 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 pre-compressed 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 pre-compressed content, perform the following steps:

ProcedureTo Change Pre-compressed Content Settings

  1. From the virtual server page, click the Content Management tab.

  2. Click General sub tab.

  3. Go to Compression > Precompressed Content section and select from the following options.

    • Precompressed Content — Enable/Disable. Allows you to instruct the server to serve pre-compressed content for the selected resource.

    • Age Checking — Specify whether to check if the compressed version is older than the non-compressed version.

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

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

    • Insert Vary Header — Specifies whether to use a Vary: Accept-encoding header.

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

      If not selected, then a Vary: Accept-encoding header is never inserted.

  4. Click Save.

Configuring the Server to Compress Content on Demand

You can also configure the Sun Java System Web Server 7.0 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 Compress Content on Demand

  1. From the virtual server page, click the Content Handling tab.

  2. Click General sub tab. Go to Compress Content on Demand section under Compression section.

  3. Select from the following options:

    • On—Demand Compression — Enable/Disable on-demand compression for the selected resource.

    • Insert Vary Header — Specify whether to insert a Vary: Accept-encoding header.

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

      If not selected, then a Vary: Accept-encoding header is never inserted.

    • 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 Save.


    Note –

    Using CLI

    For enabling compression on demand through CLI, execute the following command.


    wadm> enable-on-demand-compression --user=admin 
    --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 
    --vs=config1_vs_1 --insertvaryheader=true 
    --fragment-size=100 --compression-level=5

    See CLI Reference, enable-on-demand-compression(1).


Configuring Reverse Proxy

A reverse proxy is a proxy that appears to be a web server (origin server) to clients but in reality forwards the requests it receives to one or more origin servers. Because a reverse proxy presents itself as an origin server, clients do not need to be configured to use a reverse proxy. By configuring a given reverse proxy to forward requests to multiple similarly configured origin servers, a reverse proxy can operate as an application level software load balancer.


Note –

In a typical deployment one or more reverse proxies will be deployed between the browsers and the origin servers.


ProcedureTo Add a Proxy URI

  1. Click on Configurations tab and select the configuration.

  2. Click Virtual Servers tab and select the virtual server.

  3. Click Content Handling > Reverse Proxy tab.

  4. Click New Proxy URI button.

    Specify values for the following parameters:

    • URI — The reverse proxy URI

    • Server URL — Comma separated URLs of the remote server. If multiple values are given, the server will distribute load among the specified servers.

ProcedureTo Modify the Reverse Proxy Parameters

  1. Click on Configurations tab and select the configuration.

  2. Click Virtual Servers tab and select the virtual server.

  3. Click Content Handling > Reverse Proxy tab.

  4. Click URI

    You can edit the following parameters:

    • URI — The reverse proxy URI

    • Server URL — Comma separated URLs of the remote server. If multiple values are given, the server will distribute load among the specified servers.

    • Sticky Cookie — Name of a cookie that when present in a response, will cause subsequent requests to stick to that origin server.

    • Sticky URI Parameter — Name of a URI parameter to inspect for route information. When the URI parameter is present in a request URI and its value contains a colon `:' followed by a route ID, the request will "stick" to the origin server identified by that route ID.

    • Route Header — Name of the HTTP request header used to communicate route IDs to origin servers.

    • Route Cookie — Name of the cookie generated by the server when it encounters a sticky-cookie cookie in a response. The route-cookie cookie stores a route ID that enables the server to direct subsequent requests back to the same origin server.


    Note –

    Using CLI

    1. Invoke create-reverse-proxy command.


    wadm> create-reverse-proxy --user=admin --password-file=admin.pwd 
    --host=serverhost --port=8989 --config=test --vs=test --uri-prefix=// 
    --server=http://rick.india.sun.com:8080

    See CLI Reference, create-reverse-proxy(1).

    2. Modify obj.conf file.


    NameTrans fn="map" from="/" name="reverse-proxy-/" to="http:/"
    ...
    <Object name="reverse-proxy-/">
    Route fn="set-origin-server" server="http://rick.india.sun.com:8080"
    </Object>
    
    <Object ppath="http:*">
    Service fn="proxy-retrieve" method="*"
    </Object>

    For redirecting to a secure site, follow the same step and provide the https address for --server option.


Setting Up P3P

Platform for Privacy Preferences (P3P) enables web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats). For more information, see http://www.w3.org/P3P/.

ProcedureConfiguring Virtual Server's P3P Settings

  1. Select the Configuration.

    Select the configuration from the configuration list. Click Configurations tab to get the list of available configurations.

  2. Select the Virtual Server.

    Select the virtual server from the virtual server list. Click Virtual Servers tab to get the available virtual servers for the selected configuration.

  3. Click General tab. Configure the following settings under P3P section.

    • Enabled — Enable P3P for the selected virtual server.

    • Policy URLEnter the location of the relevant P3P policy file.

    • Compact PolicyCompact policies provide hints to user agents (browsers or other P3P applications) to enable the user agent to make quick, synchronous decisions about applying policy. Compact policies are a performance optimization that is meant by the P3P specification to be optional for either user agents or servers.


    Note –

    Using CLI

    For enabling P3P for the virtual server, execute the following command:


    wadm> enable-p3p --user=admin --password-file=admin.pwd --host=serverhost 
    --port=8989 --config=config1 --vs=config1_vs_1 --policy-url=http://xyz.com/policyurl

    See CLI Reference, enable-p3p(1).