13
Working With Virtual Hosts on Pramati
Server
Overview
Virtual hosting allows a single machine to be addressed by different names. There are two
ways for configuring Virtual Hosts. They are:
• Domain Name Service (DNS) based Virtual Domains let you host more than one site
on a single IP. With HTTP 1.1 protocol, and a common extension to HTTP 1.0, server
can identify the name with which it is being addressed.
IP based A multiple IP system can be configured to start an HTTP listener on a specific
IP. This way it can host 'n' number of sites depending on number of IPs assigned to it.
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, say,
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:
Set up the DNS services
Register any new domain names that will be used
Creating a DNS based Virtual Host using 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 name ="" doc-root="" >
<index-page/>
<static-content-headers/>
<web-log>
<log-on>true</log-on>
124
Pramati Server 3.5 Administration Guide
<dir-path>$NODE_DIR\abc</dir-path>
</web-log>
<access-constraint/>
<application>
<name/>
<allow-dir-listing/>
</application>
<alias>
<alias-name/>
<alias-directory/>
</alias>
</virtual-host>
In case a Virtual Host is configured in the web-config.xml , and ' cache-enabled
' is set to ' true ',
the user 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.StaticCacheIn-
validator" poll-interval="2" />
</cache-rule>
</virtual-host>
Definitions of configuration tags
Following is a brief description of the various tags and attributes used to configure a Virtual Host:
Table 1: Configuration Tags
Tags
Attributes Description
<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-rootThis specifies the Document Root location from where the Server serves
the requested files as *.html, *.gif, *.jsp. This is different from the default
doc root of the Server, which is: <install_root>/server/nodes/
node_name/archives/public_html.
<index-pages>
The default page that would get served if a request is made for a domain
in case the URL requested does not include one.
<static-content-headers>
This defines the static content headers.
125
CHAPTER 13
Working With Virtual Hosts on Pramati Server
A sample code for using configuration tags:
<virtual-host name="www.abc.com" doc-root="C:\VH_docRoot1">
<index-pages
name="index.htm, index.html,pramatiWelcomePage"/>
<error-pages
>
<error
code="302" url="/error/302"/>
<error
code="404" url="/error/404"/>
</error-pages>
<web-log>
<log-on>true</log-on>
<dir-path>$NODE_DIR\logs\web</dir-path>
</web-log>
<alias>
<alias-name/>
<alias-directory/>
</alias>
<allow-dir-listing>true</allow-dir-listing>
<application>
<name>WebConTests</name>
<masked-entities>
<masked-dir-list>
<masked-dir>META-INF</masked-dir>
<masked-dir>WEB-INF</masked-dir>
</masked-dir-list>
<masked-file-list>
<masked-file>. jsp</masked-file>
<masked-file>. java</masked-file>
</masked-file-list>
</masked-entities>
<web-log>
This is the root tag for web logs.
<log-on>
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 the IP based access control.
<application>
This is the root tag for application properties.
<name>
This is the name of the application
<allow-dir-listing>
This defines whether directory listing is to be enabled.
<alias>
This is the root tag for alias properties.
<alias-name>
This is the alias name
<alias-directory>
This specifies the directory where alias names are stored.
Table 1: Configuration Tags
126
Pramati Server 3.5 Administration Guide
</application>
<static-content-headers>
<entry>
<entry-identifier>Static_Content_Header_2</entry-identifier>
<url-pattern>/*</url-pattern>
<header>
<name>name</name>
<value>value</value>
</header>
</entry>
</static-content-headers>
<access-constraint>
<entry>
<entry-identifier>Access_Constraint_1</entry-identifier>
<allow-access>true</allow-access>
<url-pattern>/*</url-pattern>
<client-ip-address>127.0.0.1</client-ip-address>
</entry>
</access-constraint>
</virtual-host>
For the entries to take effect, you must restart the Server or node.
Creating a DNS based Virtual Host using Console
To create a Virtual Host using the Console:
1
Select Configure > Web Server in the Explore panel to reach the screen displaying the details for
the Hosts already configured, and the global properties of the web server.
2
Click 'Add' under 'Host' section. This displays the screen to add a Virtual Host (see the figure
given above)
3
Provide here the following details:
Clicking 'Save' brings you back to the main page of web server, displaying the added Virtual Host.
Table 2: Details needed for creating a DNS based Virtual Host
Fields
Description
Name
The domain name by which you want to set up the Virtual Host. For example VirTest.
DNS should be able to resolve this hostName 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_root>/server/nodes/
node_name/archives/public_html
127
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Fig Adding a Virtual Host
The Settings option
Clicking Settings in the 'Host' section displays a summary of the following properties for the Virtual
Host:
Basic
Header
Page Settings
Cache
URL
Web
Logs
Configuring Basic Properties for a Virtual Host
The Basic Properties section displays details about:
Table 3: Basic Properties of the Host
Fields
Description
Name
Name of the Virtual Host
Document Root
The path where all the applications will be deployed and served for the Host.
Alias
Alias name for the Virtual Host. You can have more than one alias for a single host.
128
Pramati Server 3.5 Administration Guide
Editing the Basic Properties
To modify the basic properties information, click the 'Edit' icon provided. This displays the
following screen:
Fig Editing Basic Properties of a Virtual Host
You can change the document root for the Virtual Host, and also add an Alias name for the same.
To add an Alias name, click 'Add'. On the screen that comes up, add an Alias by providing the
Name and Document root for the same.
129
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Fig Adding an Alias for a Virtual Host
Clicking 'Save' adds the Alias to the Basic properties and takes you back to the Basic Properties
screen. You can add or delete more Alias names for the Virtual Host.
Configuring Header Properties for a Virtual Host
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.
Editing the Header Properties
To edit the header properties information, click the edit icon. This displays the following screen:
Table 4: Header Properties of the Host
Fields
Description
Custom HeadersAny custom header that a user wants in response for a static page.
Content ExpirationThe time for expiration of a static page content.
130
Pramati Server 3.5 Administration Guide
Fig Editing Header Properties of a Virtual Host
Using the above screen, you can specify the custom header, and set the content expiration time for
the Virtual Host.
Adding a Custom Header property
Click 'Add' to create a new Custom Header. On the screen that is displayed, provide the Name and
Value for the same
131
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Fig Adding Custom Header Properties for a Virtual Host
Clicking 'Save' adds the Custom Header to the Header properties. You can add or delete more
Custom Headers for the Virtual Host.
Setting Content Expiration
Content expiration can be set for a static page.
Set the Content Expiration time for the Virtual Host and click 'Save' to go back to the summary
screen.
Configuring Page Settings for a Virtual Host
The Page Settings section displays details about the configured Welcome and Error pages for the
Virtual Host.
Editing Page Settings
To modify the Page Setting properties, click 'Edit'. This displays the following screen:
Table 5: Setting Content Expiration
Fields
Description
Immediately
If set as 'Immediately', the static page will not get cached by the browser or the
intermediary proxy.
After (specified) MinutesSetting the number of minutes removes the cache content after the time specified.
132
Pramati Server 3.5 Administration Guide
Fig Configuring Page Settings for a Virtual Host
Using the above screen, you can specify the Welcome and Error pages.
Adding a Welcome Page
To add a Welcome page, click 'Add'. On the screen that comes up, provide the Page name for the
same.
133
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Fig Adding a Welcome Page
Adding an Error Page
To add an Error page for the Virtual Host, click 'Add', and select the 'Type' of error to be displayed
from the drop down list provided. The types of Error pages that can be selected are:
Table 6: Types of Error Pages
Error Type
Description
400
Bad Request
401
Unauthorized
403
Forbidden
404
Not Found
405
Method Not Allowed
406
Not Acceptable
407
Proxy Authentication Required
412
Precondition Failed
414
Request-URL Too Long
415
Unsupported Media Type
500
Internal Server Error
501
Not Implemented
134
Pramati Server 3.5 Administration Guide
Specify the Page URL, say as '/error/errorpage.htm', and click 'Save' to go back to the summary
screen. The field is mandatory, and if you try to save without providing a value for it, you will be
shown an error message in the Status panel.
Fig Adding an Error Page
Configuring Cache Properties for a Virtual Host
Pramati Web Server provides rule based caching for both static and dynamic contents for
performance enhancements.
Select Configure > Web Server in the Explore panel to reach the screen displaying the details for the
configured Hosts. Select 'Settings' against the Virtual Host that you want to configure the cache for,
and scroll down on the page to the Cache section. You can view here the following details:
Maximum Cache Size. The default maximum cache size for the Virtual Host is 5MB.
Maximum Cacheable File Size. The default maximum cacheable file size is 1000Kb.
Victimization Algorithm. The Victimization Algorithm used is the Least Recently Used (LRU).
List of Default caching rules. These rules apply for all the context roots. By default there is only
one default cache rule present which represents caching of the static content.
502
Bad Gateway
Table 6: Types of Error Pages
Error Type
Description
135
CHAPTER 13
Working With Virtual Hosts on Pramati Server
The 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.
Click 'Settings' to edit the cache settings. This takes you to the page where you can modify the
Maximum cache size. It also gives you the link to add a new cache/avoid-cache/application-based-
invalidation-rule. Please click the link for adding new rules.
Read more about caching in the Technical Reference Guide .
The details displayed for the Default Application Cache rules are:
Fig Viewing Cache details
Table 7: Application Cache Rule details
Fields
Description
Name
Displays the name for the new cache rule.
Type
Displays the cache type as Cache, Avoid Cache or Application Based Invalidation.
URL
Displays the URL pattern for which the rule applies to.
HTTP MethodDisplays the HTTP method. Pramati Server 3.5 supports only the GET and PUT methods.
Status
Displays the status as either true or false. 'True' signifies that the rule is active.
Comment
Displays the comment provided for the rule.
136
Pramati Server 3.5 Administration Guide
Editing Cache Properties
To modify the Cache properties, click 'Edit'. This displays the following screen:
Fig Editing Cache Properties
Using the above screen, you can edit information for the Maximum Cache size and the Maximum
Cacheable File size. You can add cache rules at both the Host and application levels, as also clear
cache as and when required. The Algorithm used is set as 'Least Recently Used' by default.
Adding a Cache Rule
Clicking '+Add' or 'Click here to add rule' displays the 'Step 1: Add Cache Rule' screen:
137
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Fig Adding a Cache Rule
A caching rule is used to specify which page is to be cached. Provide here the following details:
Click 'Next' to define the properties for the new cache rule.
Table 8: Adding a Cache Rule
Fields
Description
Name
A unique name for the new cache rule which will be used to identify 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.
Type
Select the cache type as Cache, Avoid Cache or Application Based Invalidation, from the drop
down list provided.
Comment
A comment on the cache rule.
Context RootThe Context Root of the application. The application does not neccessarily need to have been
deployed. If a request is made for that context root, the rule will be evaluated for that request. If
the context root is not specified, the rule is considered to be a default rule which 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.
138
Pramati Server 3.5 Administration Guide
Fig Step 2 of Adding a Cache Rule
Provide here the following details:
Table 9: Adding a Cache Rule - Step 2
Fields
Description
Type
This non-editable field displays the Cache Type selected in the previous screen.
URL
The URL where the cache rule will be stored. This is a mandatory field.
HTTP Method
The HTTP Method as either GET or POST.
Use Input ParametersThere are two values for this parameter - 'all' and 'specified'. By default if no value for the
field is specified, it is 'all'.
Select whether you wish 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 will not be considered.
Add Before
The rule before which you want to add the new rule. In case nothing is selected, the rule
will be 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.
139
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Configuring Cache Expiry
The cached content must be removed when it is not acceptable. For this, you can define three types
of invalidations:
1
Time based
2
Custom based (based on invalidation rule)
3
Application based
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 the stale content is affordable or not, 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.
Expiry
The expiry time of the Customer Application based cache rules.
Input (Query String)
Parameters
The Name, Value and Condition of the Input Parameters. Specify whether you wish to use
the condition or not. You can add more Input Parameters using the button provided.
Cookie (Query String)
Settings
The Name, Value and Condition of the Cookie Settings. Specify whether you wish to use
the condition or not. You can add more Cookie Settings using the button provided.
Header (Query
String) Settings
The Name, Value and Condition of the Header Settings. Specify whether you wish to use
the condition or not. You can add more Header Settings using the button provided.
Table 10: Configuring Custom based Cache Expiry
Fields
Options
Description
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
the Cache rule.
Properties
Specify here the following properties of the Custom based cache.
Table 9: Adding a Cache Rule - Step 2
Fields
Description
140
Pramati Server 3.5 Administration Guide
Application based
This type of invalidation is meant for a typical application design where the application has two
fronts. A view front which consists of view pages and an update front which consists of pages which
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:
Defining an application based invalidation rule.
Associating cache rule with the application based invalidation rule.
Using this option, you can configure application based expiry of the Cache.
One application based invalidation rule can be referred by more than one cache rules. For example if
there are two pages say orderLines.jsp and orderDetails.jsp, both depend on some common
Name
Enter here a name for the new cache rule
Value
Provide a value for the parameter
Table 11: Configuring Application based Cache Expiry
Fields
Options Description
Select Rule
Select the application based invalidation rule from the drop down list provided.
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.
Type
Select 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.
Value
Provide a name for the target parameter or literal value based on the value of 'Maps
To' field.
Table 10: Configuring Custom based Cache Expiry
Fields
Options
Description
141
CHAPTER 13
Working With Virtual Hosts on Pramati Server
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 will be invalidated.
Configuring 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:
Configuring 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 12: Configuring Input Parameters
Fields
Options
Description
Name
Enter here a name for the new cache rule.
Value
This is an optional value for the input parameter.
Exists
Select the cache type from the drop down list provided. This parameter has
three values - mandatory, disallowed and optional.
mandatoryIt means that the input-parameter has to be present for the page to be cached.
disallowedIt means that the input-parameter must not be present for the page to be
cached.
optional
This 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 a particular condition is to be used or not.
Table 13: Configuring Cookies
Fields
Options
Description
Name
Enter here a name for the new cache rule.
Value
This is an optional value for the cookie.
Exists
Select the cache type as mandatory, optional or disallowed, from the drop down
list provided.
mandatoryIt means that the cookie has to be present for the page to be cached.
disallowedIt means that the cookie must not be present for the page to be cached.
optional
This 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 a particular condition is to be used or not.
142
Pramati Server 3.5 Administration Guide
Fig Configuring Input, Cookie and Header strings
Configuring 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 14: 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, from the drop
down list provided.
mandatory
It means that the request-header has to 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 a particular condition is to be used or not. Remember, for
using this option, the 'Use Input Parameter' field must be selected as
'specified'.
143
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Configuring URL Properties for a Virtual Host
The URL Properties section displays details about masked directory/extensions that have been
defined for applications defined on the Virtual Host.
Editing URL Properties
To view the URLs for a deployed application, you first need to deploy an application. If no
application is deployed, the following screen is displayed:
Fig URL Properties of a Virtual Host
To modify the URL properties information, click 'Edit'. This displays the following screen:
144
Pramati Server 3.5 Administration Guide
Fig Editing URL Properties of a Virtual Host
Using the above screen, you can select whether the Directory listing is to be enabled or disabled,
select the Context Root, and add Masked Directories and Extensions.
Adding 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.
145
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Fig Adding a Masked Directory
Clicking 'Save' adds the Masked Directory and takes you back to the URL Properties screen.
Adding Masked Extensions
If a file extension is masked, files of that type 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.
Deleting a Virtual Host
To delete a Virtual Host, select it using the checkbox provided and click 'Delete'.
Note: You cannot delete the Default Virtual Host.
Configuring web logs for a Virtual Host
The 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 'Edit' in this section takes you to the following screen:
146
Pramati Server 3.5 Administration Guide
Fig Configuring web log properties
Using this screen, you can specify the directory path where the log file would be generated, and
enable or disable logging. By default, logging is enabled.
Configuring global properties for a web server
You can set the following global properties for a web server:
Denial of Service attacks
MIME
Types
Connections
Socket Properties
Read more about setting the global properties for a web server in ' Configuring Pramati Web Server '.
Deploying an application on a Virtual Host
In an application deployment, the WAR may be deployed on a Virtual Host. To select the Virtual
Host:
Open the Deploy Tool and select the application to be deployed.
147
CHAPTER 13
Working With Virtual Hosts on Pramati Server
Click on 'Web Properties' node to open the General properties panel. A list of Virtual Hosts is
displayed at the bottom of the screen. Select the Virtual Host you need.
Fig Deploying an application on a Virtual Host
If you select Default, the content is deployed on default Virtual Host. If no Virtual Host is
configured, deployment is only on the default host.
Accessing information from a Virtual Host
When the Server receives a request, it checks for the name by which it is addressed. There are two
possibilities:
the name corresponds to one of the configured Virtual Hosts, and the Server tries to serve the
content from the appropriate document root (public or secure) for that Virtual Host.
the name is not found in the configuration file, and the request is served out of the default
Virtual Host.
Current limitations for Virtual Hosts
Virtual Hosts run on the same port as the default host. No separate port number configuration is
provided for them.
148
Pramati Server 3.5 Administration Guide
pdf