Working With Virtual Hosts on Pramati Server

Working With Virtual Hosts on Pramati Server 13 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, webconfig.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.staticcacheinvalidator" 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> <index-pages> <static-content-headers> name doc-root This is the root tag for Virtual Hosts. This specifies the domain name by which you want to set up the Virtual Host. DNS should be able to resolve this hostname entry. This 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. The default page that would get served if a request is made for a domain in case the URL requested does not include one. This defines the static content headers.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 125 Table 1: Configuration Tags <web-log> <log-on> <dir-path> <access-constraint> <application> <name> <allow-dir-listing> <alias> <alias-name> <alias-directory> This is the root tag for web logs. This tag helps enable or disable the web logging at the run time. This tag provides the directory location where the web log will be saved. This tag provides the IP based access control. This is the root tag for application properties. This is the name of the application This defines whether directory listing is to be enabled. This is the root tag for alias properties. This is the alias name This specifies the directory where alias names are stored. 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>

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: 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 Root The 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 Clicking Save brings you back to the main page of web server, displaying the added Virtual Host.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 127 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 Name Document Root Alias Description Name of the Virtual Host The path where all the applications will be deployed and served for the Host. 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: 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.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 129 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. Table 4: Header Properties of the Host Fields Custom Headers Content Expiration Description Any custom header that a user wants in response for a static page. The time for expiration of a static page content. Editing the Header Properties To edit the header properties information, click the edit icon. This displays the following screen:

130 Pramati Server 3.5 Administration Guide 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

CHAPTER 13 Working With Virtual Hosts on Pramati Server 131 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. 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) Minutes Setting the number of minutes removes the cache content after the time specified. 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:

132 Pramati Server 3.5 Administration Guide 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.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 133 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 Table 6: Types of Error Pages Error Type Description 502 Bad Gateway 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. 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.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 135 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-basedinvalidation-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: 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 Method Displays 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: 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:

CHAPTER 13 Working With Virtual Hosts on Pramati Server 137 Adding a Cache Rule A caching rule is used to specify which page is to be cached. Provide here the following details: 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 Root The 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. Click Next to define the properties for the new cache rule.

138 Pramati Server 3.5 Administration Guide Step 2 of Adding a Cache Rule Provide here the following details: Table 9: Adding a Cache Rule - Step 2 Fields Type URL HTTP Method Description This non-editable field displays the Cache Type selected in the previous screen. The URL where the cache rule will be stored. This is a mandatory field. The HTTP Method as either GET or POST. Use Input Parameters There 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.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 139 Table 9: Adding a Cache Rule - Step 2 Fields Description Expiry Input (Query String) Parameters Cookie (Query String) Settings Header (Query String) Settings 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 expiry time of the Customer Application based cache rules. 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. 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. 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. 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. Table 10: Configuring Custom based Cache Expiry Fields Options Description Class Check after Properties Enter here the implementation class. Specify here the time period after which a check has to be made for the expiry of the Cache rule. Specify here the following properties of the Custom based cache.

140 Pramati Server 3.5 Administration Guide Table 10: Configuring Custom based Cache Expiry Fields Options Description Name Value Enter here a name for the new cache rule Provide 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 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. Table 11: Configuring Application based Cache Expiry Fields Options Description Select Rule Input Mapping Type Source Maps To Value Select the application based invalidation rule from the drop down list provided. 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. Select here the Input Mapping type from the drop-down list as Input Parameter, Cookie, or Request Header. Enter here the name of the source parameter. Select here whether the Mapping has to be set to a target parameter or some literal value. Provide 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 rules. For example if there are two pages say orderlines.jsp and orderdetails.jsp,both depend on some common

CHAPTER 13 Working With Virtual Hosts on Pramati Server 141 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 inputparameter or the value of it. Provide the following details for Input Parameters: Table 12: Configuring Input Parameters Fields Options Description Name Value Exists Parameter in key mandatory disallowed optional Enter here a name for the new cache rule. This is an optional value for the input parameter. Select the cache type from the drop down list provided. This parameter has three values - mandatory, disallowed and optional. It means that the input-parameter has to be present for the page to be cached. It means that the input-parameter must not be present for the page to be cached. This input-parameter is optional, but if it is present, its value must match the value in the rule for the input-parameter. Select whether a particular condition is to be used or not. 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 13: Configuring Cookies Fields Options Description Name Value Exists Parameter in key mandatory disallowed optional Enter here a name for the new cache rule. This is an optional value for the cookie. Select the cache type as mandatory, optional or disallowed, from the drop down list provided. It means that the cookie has to be present for the page to be cached. It means that the cookie must not be present for the page to be cached. 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. Select whether a particular condition is to be used or not.

142 Pramati Server 3.5 Administration Guide 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 requestheader or its value. Provide the following details for configuring Headers: Table 14: Configuring Headers Fields Options Description Name Value Exists Parameter in key mandatory disallowed optional Enter here a name for the new request-header. This is an optional value for the request-header. Select the cache type as mandatory, optional or disallowed, from the drop down list provided. It means that the request-header has to be present for the page to be cached. It means that the request-header must not be present for the page to be cached. 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. 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.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 143 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: 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 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.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 145 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 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.

CHAPTER 13 Working With Virtual Hosts on Pramati Server 147 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. 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