![]() |
|
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:
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:
Table 1: 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. 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 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_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.
Table 2: 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. |
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.
The Cache section displays the following details:
Table 3: Cache properties
| Fields | Description |
|---|---|
| Maximum Cache Size | The default cache size for the virtual host is 10MB. |
| Maximum Cacheable Size | The default maximum cacheable file size is 1024KB. |
| Algorithm | The victimization algorithm used is the Least Recently Used (LRU). |
| Rules at Host Level | 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. |
| Rules at Application Level | 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. |
The details displayed for the Default Application Cache rules are:
Table 4: Application Cache Rule details
| Fields | Description |
|---|---|
| Rule Type | Displays the cache type as Cache, Avoid Cache, or Application-based Invalidation. |
| Rule Name | Displays the name for the new cache rule. |
| URL | Displays the URL pattern for which the rule applies to. |
| HTTP Method | Displays the HTTP method. Pramati Server 5.0 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. |
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.
Table 5: Adding a Cache Rule
| Fields | Description |
|---|---|
| Name | A 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. |
| 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 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
| 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 Parameters | There 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 Before | The 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. |
| Expiry | The expiry time of the customer application-based cache rules. Read Configuring Cache Expiry for further details. |
| Input (Query String) Parameters | The 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) Settings | The 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) Settings | The 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. |
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
| 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 Cache rule. |
| Properties | - | Specify here the following properties of the Custom-based cache. |
| - | Name | Enter here a name for the new cache rule. |
| - | Value | 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 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
| Fields | Options | Description |
|---|---|---|
| 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:
|
| - | Type | Select here the Input Mapping type from the drop-down list as Input Parameter, Cookie, or Request Header. |
| - | Source | Enter here the name of the source parameter. |
| - | Maps To | Select 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. |
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.
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
| Fields | Options | Description |
|---|---|---|
| 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. |
| - | mandatory | It means that the input-parameter must be present for the page to be cached. |
| - | disallowed | It 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 or not a particular condition is to be used. |
Table 10: Configuring Cookies
| Fields | Options | Description |
|---|---|---|
| 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. |
| - | mandatory | It means that the cookie must be present for the page to be cached. |
| - | disallowed | It 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 or not a particular condition is to be used. |
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. |
To modify the URL properties information, click Edit. In the page displayed, you can add, update, and delete Masked Directories and Extensions.
Clicking Save adds the Masked Directory and takes you back to the URL Properties screen.
Clicking Save adds the Masked Extension and takes you back to the URL Properties screen.
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.
Note: You cannot delete the Default Virtual Host.
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.
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.
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.
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.
Clicking Save adds the Custom Header to the Header properties. You can add or delete more Custom Headers for the virtual host.
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.
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.
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.
<bind-host-address>192.168.1.98</bind-host-address>.
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.
<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.
<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.
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).
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.
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 |