DevPortal

How do I configure Pramati Web Server?


Table of Contents


How do I configure Pramati Web Server?

The Web Server starts by default when you start the Server. Pramati Web Server serves dynamic and static Web pages for interactive applications, and supports JSP pages 2.0 and Servlets 2.4 components. The Server consists of a JSP compiler and Servlet engine, along with a secure HTTP Server. It can also be plugged into third party Web servers like Apache and IIS, and manages the execution of the Web components that run on J2EE server.

To configure the Web Server, select Configure > Web Server in the Explore panel. Here, you can configure:

How do I configure Hosts?

Virtual hosting allows a single machine to be addressed by different names. There are two ways for configuring virtual hosts. They are:

Note: This functionality is supported by Netscape Navigator 2.0 or higher, as well as Internet Explorer 3.0 or higher. Pramati HTTP Server supports name-based virtual hosting and IP multi homing.

Virtual hosts can be used to create multiple document roots on a single machine. By resolving the name-space, multiple sites can run on a single machine in an isolated manner.

Hosting multiple applications on a single HTTP Server under different domain names, for example, www.abc.com and www. def.com allows easier maintenance and better protection through isolation of files.

Before setting up virtual hosting on Pramati HTTP Server, you must:

How do I create DNS-Based Virtual Hosts using the Console?

To create a virtual host using the Console:
  1. Select Configure > Web Server in the Explore panel.
  2. Click Add under the Host section. This displays the screen to add a virtual host.
  3. Provide here the following details:

Table 1: Details needed for creating a DNS based Virtual Host

FieldsDescription
NameThe domain name by which you want to set up the virtual host. For example VirTest. DNS should be able to resolve this hostName entry. For DNS to be able to resolve this hostName entry, the name and IP should be added to the Hosts file. This file is available at C:\WINNT\system32\drivers\etc\hosts in a Windows NT system and at /etc/hosts in a Linux system. In case you try to add a name not present in the Hosts file, an error message like the following is shown: Cannot add Virtual Host :VirTest. Problem while updating web-config. problem: Can't resolve virtual host name (Invalid Entry) :VirTest No InterWiki reference defined in properties for Wiki called 'Can't resolve virtual host name (Invalid Entry) '!)
Document RootThe Document Root location from where the Server serves the requested files as *.html, *.gif, *.jsp. For example c:\VirTest\doc. This is different from the default doc root of the Server, which is <install_dir>\server\nodes\node_name\archives\public_html

Clicking Save brings you back to the main page of Web Server, displaying the added virtual host.

How do I edit Virtual Host Settings?

Clicking Settings in the Host section displays a summary of the following properties for the virtual host:

How do I edit Basic Virtual Host Properties?

The Basic Properties section displays details about:

Table 2: Basic Properties of the Host

FieldsDescription
NameName of the virtual host.
Document RootThe path where all the applications will be deployed and served for the Host.
AliasAlias name for the virtual host. You can have more than one alias for a single host.

Clicking the Edit icon displays a page where you can add or delete an Alias name for the virtual host.

To add an Alias name, click Add. On the displayed screen, provide an alias name and click Save. This adds the Alias and takes you back to the Basic Properties screen. You can add or delete more Alias names for the virtual host.

How do I edit Cache Properties for Virtual Hosts?

Pramati Web Server provides rule-based caching for both static and dynamic contents for performance enhancements.

The Cache section displays the following details:

Table 3: Cache properties

FieldsDescription
Maximum Cache SizeThe default cache size for the virtual host is 10MB.
Maximum Cacheable SizeThe default maximum cacheable file size is 1024KB.
AlgorithmThe victimization algorithm used is the Least Recently Used (LRU).
Rules at Host LevelThese rules apply for all the context roots. By default there is only one default cache rule present which represents caching of the static content.
Rules at Application LevelThe list of caching rules for the application. These are by default not there and will be displayed as and when you create a new caching rule for the context root.

The details displayed for the Default Application Cache rules are:

Table 4: Application Cache Rule details

FieldsDescription
Rule TypeDisplays the cache type as Cache, Avoid Cache, or Application-based Invalidation.
Rule NameDisplays the name for the new cache rule.
URLDisplays the URL pattern for which the rule applies to.
HTTP MethodDisplays the HTTP method. Pramati Server 5.0 supports only the GET and PUT methods.
StatusDisplays the status as either true or false. True signifies that the rule is active.
CommentDisplays the comment provided for the rule.

Click the Edit icon to modify the cache settings. This takes you to the page where you can modify information for the Maximum Cache Size and the Maximum Cacheable File Size. You can add or delete cache rules at both the Host and application levels, as also clear the cache as and when required. The Algorithm used is set as LRU by default.

The page also provides you the links to add rules at host and application levels. A new cache/avoid-cache/application-based-invalidation-rule. Click the link for adding new rules.

Read Caching for more information.

How do I add Cache Rules?

Clicking Add displays the Step 1: Add Cache Rule screen. A caching rule is used to specify which page is to be cached. Provide here the following details:

Table 5: Adding a Cache Rule

FieldsDescription
NameA unique name for the new cache rule that identifies the rule by the person who defines the rule. This is a mandatory field and not providing a value for it displays an error message in the Status panel.
TypeSelect the cache type as Cache, Avoid Cache, or Application-based Invalidation, from the drop-down list provided.
CommentA comment on the cache rule.
Context RootThe Context Root of the application. The application does not always need to have been deployed. If a request is made for that context root, the rule is evaluated for that request. If the context root is not specified, the rule is considered to be a default rule that will be evaluated for all the requests, whatever be the context root of the request. These kind of rules should be carefully used as they may lower the overall performance of the Web Server.

Click Next to define the properties for the new cache rule. Provide the following details:

Table 6: Adding a Cache Rule - Step 2

FieldsDescription
TypeThis non-editable field displays the Cache Type selected in the previous screen.
URLThe URL where the cache rule will be stored. This is a mandatory field.
HTTP MethodThe HTTP Method as either GET or POST.
Use Input ParametersThere are two values for this parameter: all and specified. The default value is all. Select whether you want to use all the input parameters in the key or only the specified input-parameters in the key. In case you select No for an input parameter under the Use Condition option, the particular parameter is not considered.
Add BeforeThe rule before which you want to add the new rule. In case nothing is selected, the rule is added to the end. The order of rules is very important. You must define the rules keeping in the mind the performance, as a rule may be getting evaluated by the request where it need not be. Also, there may be logic based on the order of the rules. The order of rules matters only between cache-rule and avoid-cache-rules. They can be merged and constitute the same list of rules for the evaluation. A rule which is significantly more frequently used than the other ones, should be kept higher in the order.
ExpiryThe expiry time of the customer application-based cache rules. Read Configuring Cache Expiry for further details.
Input (Query String) ParametersThe Name, Value, and Condition of the Input Parameters. Specify whether or not you wish to use the condition. You can add more Input Parameters using the button provided. Read Configuring Input Parameters for further details.
Cookie (Query String) SettingsThe Name, Value, and Condition of the Cookie Settings. Specify whether or not you wish to use the condition. You can add more Cookie Settings using the button provided. Read Configuring Cookies for further details.
Header (Query String) SettingsThe Name, Value, and Condition of the Header Settings. Specify whether or not you wish to use the condition. You can add more Header Settings using the button provided. Read Configuring Headers for further details.

How do I configure Cache Expiry?

The cached content must be removed when it is not acceptable. For this, you can define the following types of invalidations: The rules for invalidation must be defined in close association of caching rule for which the request is cached.

Time-Based

Time-based expiry for a cached content is defined as part of caching rule where the After field value needs to be specified in minutes, hours, or days using the drop-down list provided. This is the time after which the content is invalidated after the response is cached.

This value should be specified carefully as you must be aware whether or not the stale content is affordable, and if it is, for how much time. A typical usage may be a system where data is updated every day. Here the pages can be cached for expiry of 24 hrs starting from the time the data is updated the first time.

Custom-Based

This type of invalidation rule specifies an invalidation mechanism where you are given the flexibility to write your own logic for invalidation of the cached content. This interface provides a customizable means to invalidate the cache. Using this option, you can configure the Cache to expire based on the invalidation rule set earlier.

Table 7: Configuring Custom-based Cache Expiry

FieldsOptionsDescription
Class-Enter here the implementation class.
Check after-Specify here the time period after which a check has to be made for the expiry of Cache rule.
Properties-Specify here the following properties of the Custom-based cache.
-NameEnter here a name for the new cache rule.
-ValueProvide a value for the parameter.

Application-Based

This type of invalidation is meant for a typical application design where the application has two fronts. A view front that consists of view pages, and an update front, which consists of pages that exclusively update the data of the cached view pages. That is, there is no other interaction with the data except for the application server.

There are two things involved in these kind of invalidations:

Table 8: Configuring Application-based Cache Expiry

FieldsOptionsDescription
Select Rule-Select the application-based invalidation rule using the drop-down list.
Input Mapping-Specify which parameter (say, order_no for orderDetails.jsp) of the cached request should match which parameter (say, orderId for updateOrder.jsp) of updation page. The first is referred as source and the other as target. Source can be source-input-param, source-cookie or source-request-header and target can be target-input-param, target-cookie, target-request-header or an absolute value say 002 in our example. It must be kept in mind that:
  • If source is source-input-param, target has to be target-input-param or an absolute value.

  • If source is source-cookie, target has to be target-cookie or an absolute value.

  • If source is source-request-header, target has to be target-request-header or an absolute value.
-TypeSelect here the Input Mapping type from the drop-down list as Input Parameter, Cookie, or Request Header.
-SourceEnter here the name of the source parameter.
-Maps ToSelect here whether the Mapping has to be set to a target parameter or some literal value.
-ValueProvide a name for the target parameter or literal value based on the value of Maps To field.

One application-based invalidation rule can be referred by more than one cache rule.

For example, if there are two pages say orderLines.jsp and orderDetails.jsp, and both depend on some common JSP, say updateOrder.jsp, then we need to define an application-based invalidation rule which is satisfied by updateOrder.jsp and as and when a request comes to this rule, the concerned cached content for orderDetails.jsp and orderLines.jsp is invalidated.

How do I configure Input Parameters?

This mapping may be specified for a rule if the response varies, based upon the presence of an input-parameter or the value of it. Provide the following details for input parameters:

Table 9: Configuring Input Parameters

FieldsOptionsDescription
Name-Enter here a name for the new cache rule.
Value-Enter here an optional value for the input parameter.
Exists-Select the cache type as mandatory, optional, or disallowed, using the drop-down list.
-mandatoryIt means that the input-parameter must be present for the page to be cached.
-disallowedIt means that the input-parameter must not be present for the page to be cached.
-optionalThis input-parameter is optional, but if it is present, its value must match the value in the rule for the input-parameter.
Parameter in key-Select whether or not a particular condition is to be used.

How do I configure Cookies?

This mapping may be specified for a rule if the response varies based upon the presence of a cookie or the value of it. Provide the following details for configuring cookies:

Table 10: Configuring Cookies

FieldsOptionsDescription
Name-Enter here a name for the new cache rule.
Value-Enter here is an optional value for the cookie.
Exists-Select the cache type as mandatory, optional, or disallowed, using the drop-down list.
-mandatoryIt means that the cookie must be present for the page to be cached.
-disallowedIt means that the cookie must not be present for the page to be cached.
-optionalThis cookie is optional, but if it is present, its value must match the value in the rule for the cookie. Default value is optional.
Parameter in key-Select whether or not a particular condition is to be used.

How do I configure Headers?

This mapping may be specified for a rule if the response varies based upon the presence of a request-header or its value. Provide the following details for configuring headers:

Table 11: Configuring Headers

Fields Options Description
Name - Enter here a name for the new request-header.
Value - This is an optional value for the request-header.
Exists - Select the cache type as mandatory, optional, or disallowed, using the drop-down list.
- mandatory It means that the request-header must be present for the page to be cached.
- disallowed It means that the request-header must not be present for the page to be cached.
- optional It means that this request-header is optional, but if it is present, its value must match the value in the rule for the request-header. Default value is optional.
Parameter in key - Select whether or not a particular condition is to be used. Remember, for using this option, the Use Input Parameter field must be selected as specified.

How do I edit URL Properties for Virtual Hosts?

The URL Properties section displays details about masked directory and extensions that have been defined for applications defined on the virtual host.

To modify the URL properties information, click Edit. In the page displayed, you can add, update, and delete Masked Directories and Extensions.

How do I add Masked Directories?

If a directory is specified as masked, the contents of the directory are hidden, and any requests on them are not served. To add Masked Directories, you must first select the Context Root from the drop-down list, and then click Add. On the screen that is displayed, provide the Name and Context Root for the Masked Directory.

Clicking Save adds the Masked Directory and takes you back to the URL Properties screen.

How do I add Masked Extensions?

Files whose extension is masked cannot be accessed. To add Masked Extensions, you must first select the Context Root from the drop-down list, and then click Add. On the screen that is displayed, provide the Name and Context Root for the Masked Extension.

Clicking Save adds the Masked Extension and takes you back to the URL Properties screen.

How do I configure Web Logs for Virtual Hosts?

Web logs are used to maintain the logged records of the activities on the created virtual host. If the logging activity is disabled, the logs of activities being performed cannot be maintained.

Clicking the Edit icon in the Web Logs Properties section takes you to a page where you can specify the directory path where the log file would be generated, and enable or disable logging. Logging is enabled by default.

How do I delete Virtual Hosts?

To delete a virtual host, select it using the check box provided and click Delete.

Note: You cannot delete the Default Virtual Host.

How do I configure Global Properties for Web Server?

You can set the following global properties for a Web Server:

How do I configure Denial of Service?

In a typical connection, you may send a message asking the Server to authenticate the connection. The Server returns the authentication approval to you for acknowledgement. This connection is then allowed onto the Server.

Denial of Service (DoS) is a tool to prevent hackers who try to bring the Server down by pumping in requests. Several authentication requests are sent to the Server, filling it up. All requests have false return addresses, so the Server cannot find the user when it tries to send the authentication approval. The server waits, sometimes more than a minute, before closing the connection.

When it does close the connection, the attacker sends a new batch of forged requests, and the process begins again - tying up the service indefinitely.

In simple terms, it is possible to cause a DoS by requesting an invalid URL. Pramati Server provides a measure against such an attack by specifically asking you to provide information about:

Table 12: Details needed for Configuring the Denial of Service

Fields Description
Denial of Service Enabled Whether or not the Denial of Service is enabled.
URL Length The length of the URL. The default value used is 1024 bytes.
Max No of Headers The maximum number of headers that can be specified. The default value used is 100.
Header Length The length of the header. The default value used is 1024 bytes.
Content Size The size of the content. The default value used is 1048576 bytes.
Max number of keep-alive requests The maximum number of requests that can be kept alive. The default value used is 100.

Clicking the Edit icon displays a screen for modifying the above values. All the above values are mandatory and need to be specified.

How do I configure MIME Types?

Multipurpose Internet Mail Extensions (MIME) types represent file types as presented to your Web browser. The MIME type option allows you to specify which types of files you can open with your Web browser.

The MIME types provide information about:

Table 13: Details needed for Configuring the MIME types

Fields Description
Extension The extension of the file type, for example *.jpg.
MIME Types The MIME Content Type has a type and sub-type separated by a slash, for example, image/jpeg.

Clicking the Edit icon displays a screen for modifying the above values.

Adding MIME Types

Clicking on Add, you can add a new MIME Type by specifying its extension and MIME type.

Deleting MIME Types

You can delete an existing MIME type by selecting it using the check box provided and clicking Delete.

Click Save to return to the main page. The added MIME Type is displayed.

How do I configure Page Settings?

The Page Settings section displays details about the configured Welcome pages for the entire Web Server. To modify the Page Setting properties, click the Edit icon. In this page, you can specify the Welcome pages.

Adding Welcome Pages

To add a welcome page, click Add. On the screen that comes up, provide the Page name for the same and save settings.

Adding Directory Listing

To add a directory listing, click Add. On the screen that comes up, provide the Listing name and save settings.

How do I configure Header Properties?

HTTP requests and HTTP responses use headers to send information about the HTTP message. The Header Properties section displays details about the Custom Headers and Content Expiration.

Table 14: Header Properties of the Host

Fields Description
Applicable URL Patterns The Custom Header information will be added in the HTTP Response for every Request matching these patterns.
Apply to all static content Whether or not the properties will apply to all static content.
Custom Headers Any custom header that you may want in response for a static page. The Name-Value pairs declared in Custom Headers will be sent in the HTTP Header of every Response to URLs matching the pattern defined above.

To edit the header properties information, click the Edit icon. In this page, you can specify the custom header, and set the content expiration time for the virtual host.

Applying to all Static Content

This indicates whether or not the Header properties will apply to all static content. If enabled, all the custom headers specified get added to the response sent for all the static pages requested.

In <url-pattern>, the URL pattern can be specified as:

Table 15: Resource tags

Resource Tags Description
<resource> Can contain multiple header tags
<name> Contains the header name
<value> Contains the value for that header

Adding Applicable URL Patterns Click Add to create a new URL Pattern. On the screen that is displayed, provide the URL Pattern to be added.

Clicking Save adds the URL Pattern to the Header properties. You can add or delete more URL Patterns for the virtual host.

How do I add Custom Header Properties?

Click Add to create a new Custom Header. On the screen that is displayed, provide the Name and Value for the same.

Clicking Save adds the Custom Header to the Header properties. You can add or delete more Custom Headers for the virtual host.

How do I configure Connections?

Connections provide information about:

Table 16: Details needed for Configuring the Connections

Fields Description
Maximum Acceptor Threads The maximum number of acceptor threads allowed
Maximum Secure Acceptor Threads The number of secure acceptor threads allowed
Timeout The timeout for connections, specified in milliseconds

Clicking the Edit icon displays a screen for modifying the above values.

How do I configure Socket Properties?

The Socket Properties give information about:

Table 17: Details needed for Configuring the Socket Properties

Fields Description
TCP No Delay Whether or not there is TCP delay. Written data to the network is not buffered pending acknowledgement of previously written data. The default is set to true.
Socket Linger Specify a linger-on-close timeout. This option disables/enables immediate return from a close() of a TCP Socket. The default is set to -1 msec.
Connection Keep-Alive Whether or not the connection is to be kept alive. The default is set to true.
Idle Timeout Idle timeout is how long the Web Server listens on an idle socket before closing it. The default value is -1 which means that Keep-Alive Timeout is applicable instead. Setting this value can result in lesser performance, so it should be set only when necessary.
Send Buffer Size Set the size of the underlying buffers used by the platform for outgoing network I/O. The default size is 8192 bytes.
Receive Buffer Size Set the size of the underlying buffers used by the platform for incoming network I/O. The default size is 8192 bytes.
Socket Timeout The socket timeout for server socket of the server listening on the Web port specified. The default value of socket timeout is set to 0 msec.
Keep-Alive Timeout The default value of keep-alive timeout is set to 3000 msec.

Clicking the Edit icon displays a screen for modifying the above values.

How do I configure Deviation from Specifications?

The deviation from specifications gives information about:

Table 18: Details needed for Configuring the Deviation from Specifications

Fields Description
Default JSP Imports Enabled Whether or not the default JSP imports is enabled. The default is set to false.
JSP Parsing Strict The default is set to false.
Tomcat Mode Enabled Whether or not the Tomcat mode is enabled. The default is set to true.
JSP Buffer Size The default value is 8192 bytes.
Write After Close Enabled Whether or not the write-after-close is enabled. The default is set to true.
Using Both response Streams Enabled Whether or not using both response streams is enabled. The default is set to false.
Is DefaultContent set Whether or not the DefaultContent is set. The default is set to true.
Default JSP Imports This should be specified using comma separated list of imports. For example, java.io.*, java.util.*
Default Content Type The default value of content type is set to text/html. This should not have any control-characters/whitespace. It should also have a /.

Clicking the Edit icon displays a screen for modifying the above values.

How do I modify HTTP Server Configuration using IPs?

To modify the HTTP server configuration using IPs, you have to specify an IP address on which you want to start the server, say, <bind-host-address>192.168.1.98</bind-host-address>.

How do I check IP Address using the web-config.xml?

A new tag introduced in the web-config.xml helps Web Server administrators to allow or restrict access to Web resources. This can be specified in the Acess Constraints Lists (ACLs) in the Web servers access constraints, based on the IP addresses of the requesting client.

The constraints specified in the ACLs check the URL pattern specified. This specified URL pattern should be in the directory pattern, that is, ending with /*. extension pattern and exact pattern are ignored even if specified. Any number of entries can be added to the web-config.xml as needed. The structure of access constraint tag in web-config.xml is as follows:

<access-constraint enable="true">
  <entry>
    <entry-identifier>Sample_1</entry-identifier>
    <allow-access>true</allow-access>
    <url-pattern>abc/pqr/*</url-pattern>
    <url-pattern>mno/abc/*</url-pattern>
    <client-ip-address>192.167.1.2</client-ip-address>
    <client-ip-address>192.167.1.14</client-ip-address>
  </entry>
</access-constraint>

Set enable="true" to enable IP Address Checks. The attribute is set to false by default to improve Server performance. The <access-control-list> tag is used to define the URL and patterns for which the aceess is restricted or conditionally allowed.

In the <allow-access> tag, you can allow or restrict access. The list of IP addresses allowed and restricted may be specified in the <client-ip-address> tag. Wild card characters are supported, and should be specified as *.*.*.; but domain names cannot be specified as IP addresses. If localhost is allowed, it should be specified as 127.0.0.1. Following are a few examples on how Access-Constraints work.

Example 1

<access-constraint enable="true">
  <entry>
    <entry-identifier>Sample_1</entry-identifier>
    <allow-access>true</allow-access>
    <url-pattern>abc/pqr/*</url-pattern>
    <url-pattern>mno/abc/*</url-pattern>
    <client-ip-address>192.167.1.2</client-ip-address>
    <client-ip-address>192.167.1.14</client-ip-address>
  </entry>
</access-constraint>
Above access constraints mean "Allow access for abc/pqr/* and mno/abc/* patterns for requests coming from 192.167.1.14 and 192.167.1.2". Requests from all others hosts are restricted, that is, they are forbidden.

Example 2

<access-constraint enable="true">
  <entry>
    <entry-identifier>Sample_1</entry-identifier>
    <allow-access>false</allow-access>
    <url-pattern>abc/pqr/*</url-pattern>
    <url-pattern>mno/abc/*</url-pattern>
    <client-ip-address>192.167.1.2</client-ip-address>
    <client-ip-address>192.167.1.14</client-ip-address>
  </entry>
</access-constraint>

Above access constraints mean "Don’t allow access for abc/pqr/* and mno/abc/* patterns for requests coming from 192.167.1.14 and 192.167.1.2", that is, they are forbidden. Requests from all others hosts are allowed, that is, the request is served.

How do I reload JSPs and Servlets?

Refreshing JSPs and Servlets in the Server allows it to check for changes in the JSP or Servlet files and reloads them into the Server VM. This is very helpful in a development scenario, where changes to the JSPs or servlets are made frequently, and developers may want to look at the changes immediately. This avoids a restart of the application (or the Server).

By editing the tag in the web-config.xml file, the Server can be made to check for any changes in the JSPs. Following is the tag:

<update-check-interval-seconds>2</update-check-interval-seconds>

Entering a negative value disables the check. In production environments, it may be desirable to have the Server check for updates once in 600 seconds (or similar intervals depending on the frequency of change).

How do I create DNS-Based Virtual Hosts using the web-config.xml?

Virtual hosts are registered with Pramati HTTP Server through a configuration file, web-config.xml and web-cache.xml, located at <install_dir>/server/nodes/<node_name>/config/.

Add an entry in this xml configuration file for every virtual host configured. A sample entry is shown below:

<virtual-host doc-root="/home/peter/Xtras/PeterHost" name="peterhost">
  <web-log>
	<log-enabled>true</log-enabled>
	<dir-path></dir-path>
	<batch enable="true">
		<size>5000</size>
		<flush-duration-millis>100</flush-duration-millis>
	</batch>
  </web-log>
  <access-constraints/>
  <application>
	<name/>
	<masked-entities>
		<masked-dir-list/>
		<masked-file-list/>
	</masked-entities>
  </application>
  <alias>
	<alias-name></alias-name>
  </alias>
</virtual-host>

If a virtual host is configured in the web-config.xml, and cache-enabled is set to true, you should make the following entry in the web-cache.xml apart from the entry already available there:

<virtual-host name="virtual host name">
  <max-cache-size-mb>5</max-cache-size-mb>
  <max-cacheable-file-size-kb>1000</max-cacheable-file-size-kb>
  <victim-selection>LRU</victim-selection>
  <cache-rule name="static-cache-rule" request-uri="static-cache-rule">
    <custom-invalidator class-name="com.pramati.web.dyncache.StaticCacheInvalidator" poll-interval="2"/>
  </cache-rule>
</virtual-host>

Note: It is recommended that you use the Console to update any settings for Virtual Hosts.

How do I define Configuration Tags?

Following is a brief description of the various tags and attributes used to configure a virtual host:

Table 19: Configuration tags

Tag Attribute Value
<virtual-host> - This is the root tag for virtual hosts.
- name This specifies the domain name by which you want to set up the virtual host. DNS should be able to resolve this hostName entry.
- doc-root This specifies the Document Root location from where the Server serves the requested files as .html, .gif, and .jsp. This is different from the default doc root of the Server, which is <install_dir>\server\nodes\node_name\archives\public_html.
<web-log> - This is the root tag for Web logs.
<log-enabled> - This tag helps enable or disable the Web logging at the run time.
<dir-path> - This tag provides the directory location where the Web log will be saved.
<access-constraint> - This tag provides IP-based access control.
<application> - This is the root tag for application properties.
<name> - This is the name of the application.
<alias> - This is the root tag for alias properties.
<alias-name> - This is the alias name.


© Pramati Technologies 2007 Runs on Pramati Server | Feedback | Legal