Page History

...

...

...

...

...

When configuring a user defined transaction name, you will need to specify the display mode between the <display-mode> tags. Possible values are:

• prefix. This will place the value in the before the original transaction name.

• override. This will replace the original transaction name with the configure transaction name.

  Info

...

• When you configure a user defined transaction name, verify that it is a field with little variance (not many different values). For example, the cookie APP_VIEW is a good candidate to be used. In contrary to the SESSION_ID, which is a bad candidate, as it has a very large range of values. When you have a very large range of values, the Precise for Web schema tables grow very large.

To add a cookie - example

• If you have a cookie called USER_NAME in your application, you may add it to the user interface (as User Name), by adding the following UserDefined element:

<user-defined-transaction-name>
          <cookie-name>USER_NAME</cookie-name>
          <display-mode>prefix</display-mode>
</user-defined-transaction-name>

To add a dom element - example

• If you want to add the Title (DOM element) of your Web pages to the user interface (as My Title), you can add the following UserDefined element:

<user-defined-transaction-name>
          <dom-element>document.title</dom-element>
          <display-mode>prefix</display-mode>
</user-defined-transaction-name>

If the client-side agent is not installed on your Web server (only server-side is installed), you can not collect the Title DOM element.

...

By configuring the element user-defined-client-ip, you can change the way that client IP is collected by the server-side agent. You can instruct Precise for Web to collect the client IP from 3 different sources (instead of the HTTP request itself):

• Cookie
• Request header

• URL parameter

  Info

...

• You may want to change the way the client IP is collected when the Web server is behind some proxy, in which case the collected client IP is always the IP of the proxy.

apache-virtual-hosts

To separate Apache Virtual Hosts in different Precise applications, the Precise administrator needs to perform the following steps:1.    Create

1. Create an Application in Precise for each Virtual Host. (For more information, see the Working with the Application Installer wizard section in the Precise Installation Guide.)

...

1. Place the Apache instance in the multiple instance view in each of the defined Precise applications.

...

1. Go to the instance registry and set the a registry entry for each of the Virtual Hosts using the following format:
   <virtual-host-settings>
        <vhost-i>
             <vhost-name>name</vhost-name>
             <precise-application-name>application_name</precise-application-name>
        </vhost-i>
        …
             <!-- map all unmapped Virtual Hosts to this env (if not defined the information will be discarded) -->
        <vhost-i>
             <vhost-name>default</vhost-name>
             <precise-application-name>application_name</precise-application-name>
        </vhost-i>
   <virtual-host-settings>

   Info

...

1. In a case of an unmapped Virtual Host, transactions can either be displayed in the “default” application (“default” is set), or discarded if “default” is not set.

...

1. Restart the Web Collector on the monitored server by performing the following steps

...

1. .
   1. Go to AdminPoint>Agents.

...

1. 1. Click Stop to stop all Web agents on the monitored server.

...

1. 1. Click Start to start all Web agents on the monitored server.

After performing these steps, you will see the unique information of each Virtual Host in each of the defined Precise applications.

...

• Once the instance is configured as defined, each of the Virtual Hosts are linked to a specific application in Precise and the information cannot be shared in a multiple instance view.
• J2ee instances which are shared between two applications can cause unexpected results, and thus should be defined in two Virtual Host Precise applications.

Server registry

Configuring the server registry affects the Web collector and the instances on the server.

server-side

Table 9-6    client6 client-side section

...

...

Table 9-7    verify 7 verify section (inside web-collector)
Registry elements    Description
max-user-agent-length    Maximum allowed user agent (browser type) length. Records exceeding this value will be ignored (not loaded).
Units: bytes
Default: 256
max-user-defined-length    Maximum allowed user defined 1 & 2 length. Records exceeding this value will be ignored (not loaded).
Units: bytes
Default: 256
Table 9-8    server8 server-side section (inside verify, inside web-collector)
Registry elements    Description
max-server-period    Maximum allowed server period (not including network period). Records exceeding this value will be ignored (not loaded).
Units: milliseconds
Default: 3600000 (1 hour)
max-future-time    Maximum allowed difference between current time and future record time. Records that have a later time the allowed will be ignored (not loaded).
Units: milliseconds
Default: 86400000 (1 day)
empty-http-status-allowed    If true, records with no HTTP status are not ignored. Default: true
fallback-http-status    If a record does not contain HTTP status and empty-http-status-allowed is set to true, sets the value to use for the HTTP status of that record.
Default: 0
min-http-status, max-http-status    If fallback-http-status is not set (or set to 0) HTTP statuses outside this range cause the record to be ignored (not loaded).
Default: 0, 599
empty-protocol-allowed    If true, records with no HTTP protocol are not ignored. Default: true
max-protocol-length    If the length of the HTTP protocol of a record exceeds this value, the record will be ignored (not loaded).
Units: bytes
Default: 5
allowed-protocols    If this is set, only HTTP protocols in this list are allowed, other values will cause the record to be ignored (not loaded).
Default: none
empty-http-method-allowed    If true, records with no HTTP method are not ignored. Default: true
fallback-http-method    If a record does not contain HTTP method and empty-http-method-allowed is set to true, sets the value to use for the HTTP method of that record.
Default: GET
allowed-http-methods    If this is set, only HTTP methods in this list are allowed, other values will cause the record to be ignored (not loaded).
Default: none
Table 9-9    client9 client-side section (inside verify, inside web-collector)
Registry elements    Description
max-text-period    Maximum allowed text period. Records exceeding this value will be ignored
(not loaded).
Units: milliseconds
Default: 900000 (15 minutes)
max-rendering-period    Maximum allowed rendering period. Records exceeding this value will be ignored (not loaded).
Units: milliseconds
Default: 900000 (15 minutes)
The entries below are similar for 4 sections (with one exception*):
Table 9-10    summed 10 summed section (inside server-side, inside output, inside web-collector) raw section (inside server-side, inside output, inside web-collector) summed section (inside client-side, inside output, inside web-collector) raw section (inside client -side, inside output, inside web-collector)
Registry elements    Description
max-files    Maximum files allowed in the output directory. After exceeding this value, no more files will not be written.
Default: 1440
max-recs-in-file    Maximum records allowed in 1 output file. After exceeding this value, a new file will be created.
Default: 10000
max-time-to-write-file    Maximum time to have 1 file open. Units: milliseconds
*Default for summed: 900000 (15 minutes)
*Default for raw: 60000 (1 minute)
max-file-size    Set the maximum for file size. Units: bytes
Default: 10485760 (10MB)
Table 9-11    server11 server-side section (inside tac, inside smartlink, inside web-collector)
client-side section (inside tac, inside smartlink, inside web-collector)
Registry elements    Description
max-files    Maximum files allowed in the output directory. After exceeding this value, no more files will not be written.
Default: 1440
max-recs-in-file    Maximum records allowed in 1 output file. After exceeding this value, a new file will be created.
Default: 10000
max-file-size    Set the maximum for file size. Units: bytes
Default: 10485760 (10MB)
Table 9-12    server12 server-side section (inside input, inside web-collector)
client-side section (inside input, inside web-collector)
Registry elements    Description
delete-files    When set to true, input raw files are deleted after being processed. Default: true
max-error-files    Maximum number of error files to move to the errors directory when errors occur on files.
Default: 10
Table 9-13    statistics 13 statistics section (inside ivp, inside web-collector)
Registry elements    Description
enabled    When set to false, validation of the statistics component of the web collector are not performed in the verify action (in AdminPoint).
Default: true
Table 9-14    processing 14 processing section (inside ivp, inside web-collector)
Registry elements    Description
Enabled    When set to false, validation of the core web collector are not performed in the verify action (in AdminPoint).
Default: true
server-amount-limit-for-no-client    When client/server correlation is enabled, the web collector warns - in the verify action (in AdminPoint) – that server records were received but no client records did. This number sets the threshold for this warning.
Default: 1000
client-amount-limit-for-no-server    When client/server correlation is enabled, the web collector warns - in the verify action (in AdminPoint) – that client records were received but no server records did. This number sets the threshold for this warning.
Default: 500
server-amount-limit-for-no-network    When server/network correlation is enabled, the web collector warns - in the verify action (in AdminPoint) – that server records were received but no network records did. This number sets the threshold for this warning.
Default: 1000
network-amount-limit-for-no-server    When server/network correlation is enabled, the web collector warns - in the verify action (in AdminPoint) – that network records were received but no server records did. This number sets the threshold for this warning.
Default: 1000
 Table Table 9-15    web15 web-collector section
Registry elements    Description
preferred-data-port    Will be used by the web collector for communication with server and network agents. If this port is busy, any available port will be used.
Default: 20999
Table 9-16    summary 16 summary section (inside web-collector)
Registry elements    Description
enabled    When set to false, summary processing is not performed by the web collector. This setting is meaningful only on the monitored server (and not on the FP machine where it is ignored). Setting this to false (along with client-server-correlation) sets the work mode to Basic Mode.
Default: true
Table 9-17    server17 server-side section
Registry elements    Description
Enabled    When set to false, server-side collection is disabled. Default: true
client-server-correlation    When set to false, client/server correlation is disabled and in fact the instance will work in Basic Mode (this does not have meaning on the FP machine).
Default: true
server-network-correlation    When set to false, server/network correlation is disabled (this does not have meaning on the FP machine).
Default: true
filter-do-collector-settings    When set to false, collector settings activity (handling of URL parameters)
is done in the web collector instead of in the web filter. Default: true (processing done on filter)
filter-do-data-patterns    When set to false, data patterns processing is done in the web collector instead of in the web filter.
Default: true (processing done on filter)
filter-do-locations    When set to false, data locations processing is done in the web collector, instead of the web filter.
Default: true (processing done on filter)
Table 9-18    client18 client-side section
Registry elements    Description
enabled    When set to false client-side collection is disabled
Default: true
Table 9-19    statistics 19 statistics section
Registry elements    Description
enabled    When set to false statistics collection is disabled
Default: true
max-files (in output section)    Maximum files allowed in the output directory. After exceeding this value, no more files will not be written.
Default: 2000
Table 9-20    processing 20 processing section (inside web-collector)
Registry elements    Description
max-data-processor-threads    Maximum number of threads that will be invoked by the web collector to handle data.
Default: 50
write-dp-period-ms    The initial wait time of the serialization timer that serializes the current data to files.
Units: milliseconds
Default: 120000
write-dp-delay-ms    The cycle time of the serialization timer that serializes the current data to files.
Units: milliseconds
Default: 120000
Table 9-21    server21 server-side section (inside processing, inside web-collector))
Registry elements    Description
input-queue-max-size    Set the maximum number of records in the input queue. After the queue reaches this size, we start dropping records. May be used to temporarily ease memory consumption.
Default: 15000
aging-period    Max time for server records to wait in memory for correlation (with both client & network records).
Units: milliseconds
Default: 90000 (1.5 minutes)
aging-period-when-using-client-collector    Max time for server records to wait in memory for correlation (with both client & network records) when this instance uses the client collector.
Units: milliseconds
Default: 30000 (30 seconds)
Table 9-22    client22 client-side section (inside processing, inside web-collector)
Registry elements    Description
input-queue-max-size    Set the maximum number of records in the input queue. After the queue reaches this size, we start dropping records. May be used to temporarily ease memory consumption.
Default: 10000
aging-period    Max time for client records to wait in memory for correlation (with server records).
Units: milliseconds
Default: 90000 (1.5 minutes)
aging-period-when-using-client-collector    Max time for client records to wait in memory for correlation (with server records) when this instance uses the client collector.
Units: milliseconds
Default: 180000 (3 minutes)
max-text-period-before-fix    Max time in milliseconds for client records first byte time. If the first byte time exceeds the maximum, it will be fixed by taking the server + network time.
Default: 900000 milliseconds
Table 9-23    network 23 network section (inside processing, inside web-collector)
Registry elements    Description
input-queue-max-size    Set the maximum number of records in the input queue. After the queue reaches this size, we start dropping records. May be used to temporarily ease memory consumption.
Default: 15000
aging-period    Max time for network records to wait in memory for correlation (with server records).
Units: milliseconds
Default: 90000 (1.5 minutes)
Table 9-24    server24 server-side section (inside filtering, inside web-collector)
Registry elements    Description
enabled    When set to false, server-side filtering is disabled
Default: true
reset-identifiers    A list of identifiers that will be reset in the filtering-summary process (when needed).
The identifiers will be reset, one by one, in the order they appear here until the top N limit is reached.
Valid values:
url, domain, userAgent, userDefined1, userDefined2, appUserName, clientIP, location,
city, state, country, siebelView, urlParams, protocol, httpMethod, sessionID
Default: httpMethod, userAgent, protocol
Table 9-25    client25 client-side section (inside filtering, inside web-collector)
Registry elements    Description
enabled    When set to false, client-side filtering is disabled
Default: true
reset-identifiers    A list of identifiers that will be reset in the filtering-summary process (when needed).
The identifiers will be reset, one by one, in the order they appear here until the top N limit is reached.
Valid values:
url, domain, protocol, userAgent, userDefined1, userDefined2, appUserName, clientIP, location,
city, state, country, siebelView, title
host connectionType privateIP
login
Default: userAgent, protocol
FocalPoint registry
The following section describes the FocalPoint registry element.
user-agents
The user-agent element consists of a set of definitions of user agents. A user agent is a device that may access a Web server. A typical user agent is a browser like Microsoft Internet Explorer or Firefox. Other types of user agents are automatic HTTP traffic generators, like Precise Insight Inquire. The Precise for Web Collector agent, automatically collects the user agent of every request that it monitors. To extract a comprehensive user agent name and version from the user agent header of the request, the agent uses the definitions in the user-agents element. By default, the user-agent element contains a definition for most of the industry’s known Web servers, like Microsoft Internet Explorer, Firefox, Netscape, Mozilla as well as the integrative Precise Insight Inquire traffic generator. However, you can add any number of user agents to the list, or change the definition of an existing user agent to adjust it to customers private needs or conventions. For example, the definition for the Netscape browser is:
<user-agent id="Netscape" display-string="Netscape version">
<version-search-string>Netscape</version-search-string>
<search-string value="Netscape"/>
</user-agent>

...

The following table describes the registry elements for the user-agent in the FocalPoint registry.
Table 9-26    Registry 26 Registry elements
Registry element    Description
user-agent    A user agent definition that Precise for Web uses to find and describe user agents.
user-agent.id    A string identifier for the user agent. This identifier is not the display name.
user-agent.display-string    The display string that is shown in the user interface for this user agent. You can use the
version token which is replaced with the detected user agent version.

...

If you use an Apache, iPlanet, Sun ONE, WebSphere, Tomcat, Oracle Application Server, SAP, J2EE, or BEA WebLogic server, you can specify some Web filter settings that the Web server loads on startup. These parameters are the same for all Web servers. To add them, follow the instructions for the specific Web server.
See “Addable parameters” on page 132.
NOTE    Modification of IIS Web filter parameters is not yet supported.
To add parameters on an Apache server
1.    Open the httpd.conf file.
2.    After the LoadModule pssfilter_module line, add the parameter.
For example:
LoadModule pssfilter_module... PssFilterTrace 1
To add parameters on an iPlanet server
1.    Open the magnus.conf files.
2.    At the end of the Init fn=pss-init line, add the parameter.
For example:
Init fn=pss-init PssFilterTrace="1"
To add parameters on any J2EE server by editing the web.xml file
1.    Open the web.xml file.
2.    Add the parameters to the <filter> element in the following format:
<init-param>
<param-name>xxx</param-name>
<param-value>yyy</param-value>
</init-param>
For example:
<filter>
<filter-name>pssFilter</filter-name>
<description></description>
<filter-class>com.precise.ifweb.Collection.Filters.pssFilter
.WLFilter</filter-class>
<init-param>
<param-name>PssFilterTrace</param-name>
<param-value>1</param-value>
</init-param>
</filter>
Addable parameters
The following table lists all parameters that you can add to the Web filters. This mechanism should only be used for the instance name and <i3_root>. Any other parameter should only be added after consultation with the Precise Enterprise Support Team.
Table 9-27    Addable 27 Addable Web filter parameters
Parameter    Description
PssInstanceName    Specifies the name of the filter’s instance.
PssInstanceID    The instance ID as specified in the infrastructure database.
PssI3Root    Specifies the path to the Precise installation directory.
PssReadConfFile    Specifies whether to read the configuration files on filter initialization. If this parameter is set to FALSE, parameters are taken from the Web server only.
Default: TRUE
PssRestartFilesPath    Specifies an alternate location for the pss_restart file. By default this file is located under the directories of the Web server itself (the exact location is web server type dependent). Set this to a different path if the file cannot be created at the default location.
PssInitLog    Specifies whether to write initialization log messages to standard output. In some cases the standard output is written to the Web server log.
Applies only to J2EE-based application servers (Sun ONE, WebSphere, Tomcat, Oracle Application Server, SAP J2EE, or BEA WebLogic)
The following table gives a comparison of the parameter and its equivalent registry element .
Table 9-28    Parameter 28 Parameter and Registry element
Parameter    Registry element
PssFilterTrace    filter-trace
PssIgnoreFiles    filter-ignore-files
PssSessionCookieName    filter-session-cookie
PssMaxI4WCookieSize    max-i4w-cookie-size
PssCorrelationMode    web-disable-correlation
Note: The opposite of this registry element works as its equivalent parameter.
PssExtList    ext-list
PssExtListSeparator    ext-list-separator
pcs_shm_dir    general-pcs-shm-dir
PssURLEncodingName    filter-encoding-name
PssUseURLEncoding    filter-use-encoding

...

The Activity tab of Precise for Web displays information on the URLs and pages visited. In some cases, the database tables that contain this information can easily swell and harm the performance of the user interface, for example when URLs are generated automatically.
To reduce the accumulation frequency of URLs, Precise for Web lets you group consecutive URLs by pattern by editing the data-patterns registry element. Each of the data-pattern elements (urls, pages, titles, domains, and user-defined-transaction-name) can be specified with methods. The available methods are prefix, suffix, prefix-by-key, and regex.
You can add as many methods and patterns to any of the sections (<urls>, <pages>, <titles>, <domains>, <user-defined-transaction-name>).
NOTE    The tags <methodN> and <patternN> should be numbered so that 'N' is replaced with a consecutive number.
NOTE    In URLs and Pages, pattern definitions only work on the path part. For example, in the URL /index.jsp?id=&eventid=, the path part is /index.jsp and the parameters part is id=&eventid=. To handle collection definitions (aka grouping) on the parameters part, refer to the Collector Settings section. In the above example, any pattern that is defined on the URL, ignores the parameters part (id=&eventid=).
The following table describes the available methods.
Table 9-29    methods29 methods
Method    Description
prefix    Take only the defined prefix.
For example: <pattern1>abraham</pattern1> - For URL 'abraham123.html' you will see
'abraham%'.
suffix    Take only the defined suffix.
For example: <pattern1>html</pattern1> - For URL 'abraham123.html' you will see '%html'.
prefix-by-key    Take text up to the defined key (not including that key).
For example: <pattern1>;jsessionid</pattern1> - For URL 'abraham123.html;jsessionid' you will see 'abraham123.html%' (if showReplaceChar="false", you will get 'abraham123.html').
regex    Use the given regular expression to change the given URL.
For example: <pattern1 replace="$1">service(.*)</pattern1> - For URL 'service123' you will get '123' (for more on regular expressions, consult your support representative).
The following code is an example of the element’s content for an URL element when all the grouping methods are activated:
<data-patterns>
<urls>
<execute>true</execute>
<methods>
<method1>
<name>prefix</name>
<patterns>
<pattern1>/redirectlogon.html</pattern1>
</patterns>
</method1>
<method2>
<name>suffix</name>
<patterns>
<pattern2>ads.com</pattern2>
</patterns>
</method2>
<method3>
<name>prefix-by-key</name>
<patterns>
<pattern3>:jsessionid=</pattern3>
</patterns>
</method3>
<method4>
<name>regex</name>
<patterns>
<pattern4 replace="$1">\d+: (.*)</pattern4>
<patterns/>
</method4>
</methods>
</urls>
</data-patterns>
When URL pattern prefix grouping is activated, a percentage sign (%) is added at the end of a URL. For example, the URL /redirectlogon.html/121231245 is saved in the database as /redirectlogon.html%.
To group consecutive URLs by pattern
1.    Open the relevant registry file (instance regisrty, server registry, or focal-point registry) and find the data-patterns element (If it does not exist, you can add it as appears in the server registry)
2.    Edit the data-patterns element in the following way:
•    Set the required <execute> elements to true.
•    Choose the method (prefix, suffix, prefix-by-key, or regex) in the required element (urls, pages, titles, domains).
•    Define the URL patterns in the <pattern> elements. You can include as many <pattern> elements as required.
•    If you choose the regex method, use the replacement string. For example:
<pattern replace=“$1”>\d+: (.*)</pattern>
3.    Save and close the file.
4.    Restart the Precise for Web server-side and dynamic instrumentation agents monitoring the relevant environment.

...

When you install a Web server agent, you are asked whether you would like to dynamically instrument Web pages. Also when you select an existing instance, you can edit it, so that the dynamic instrumentation can be applied. In both cases this results in an additional entry in the AdminPoint window. The new entry shows identical instance information for all but one column: the Agent column. In this column the agent is shown as Web Instrument agent. The Instrument.xml file handles the dynamic instrumentation configuration.
About the instrumentation configuration file (Instrument.xml)
If the instance is part of a cluster, the Instrument.xml file is located in the <FP server>\products\i3fp\registry\clusters\www\<name of cluster> directory.
If the instance is not part of a cluster, the Instrument.xml file is located in the <FP server>\products\i3fp\registry\instances\www\<monitored instance name>\<instance name> directory. if you make changes in the Instrument.xml file, then you will also have to make the changes in the proxy (or proxies). The recommended way to do so it you use the CLI command as describe before.
See “Instance registry” on page 116.
Following is an example of the file structure that is explained in the section following the example:
<dynamic-inst>
<enable>true</enable>
<handle-js>true</handle-js>
<prolog-string> <![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD
XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/ xhtml1-transitional.dtd">]]>
</prolog-string>
<no-recompress>true</no-recompress>
<accumulate-on-parsing>true</accumulate-on-parsing>
<max-parsing-bytes>2048</max-parsing-bytes>
<js-mime-type>text/javascript</js-mime-type>
<instance-id>1234</instance-id>
<strict-servlet-api>true</strict-servlet-api>
<private-log>false</private-log>
<i3-log>false</i3-log>
<webgarden>
<enable>false</enable>
<sampling-interval>2000</sampling-interval>
</webgarden>
<user-agents>
<user-agent name="debug">
<i3-log>false</i3-log>
<private-log>false</private-log>
<accumulation>default</accumulation>
<parsing>false</parsing>
<second-script>false</second-script>
<enable>true</enable>
</user-agent>
<user-agent name="MSIE">
<i3-log>false</i3-log>
<private-log>false</private-log>
<accumulation>default</accumulation>
<parsing>false</parsing>
<second-script>false</second-script>
<enable>true</enable>
</user-agent>
<user-agent name="Default">
<i3-log>false</i3-log>
<private-log>false</private-log>
<accumulation>default</accumulation>
<parsing>false</parsing>
<second-script>false</second-script>
<enable>true</enable>
</user-agent>
</user-agents>
<include-ip>
<range from="123.23.1.1" to="123.23.1.255" />
<range from="125.2.1.1" to="125.2.1.255" />
</include-ip>
<url-exclude>
<suffix>.gif</suffix>
<suffix>.jpeg</suffix>
</url-exclude>
<url-include>
<prefix>/products</prefix>
<prefix>/petstore/accounts</prefix>
<suffix>createData.dll</suffix>
</url-include>
<include-char-encoding>
<char-enc>shift_jis</char-enc>
<char-enc>jis</char-enc>
</include-char-encoding>
<req-header-exclude>
<header name="content-type" value="application/x-www-form- urlencoded" />
</req-header-exclude>
</dynamic-inst>
About the Instrument.xml tags
The following table contains the tags that can be encountered in the Instrument.xml file. "not applicable" means that the tag has no influence on that specifically chosen instance type.
Table 9-30    Instrument30 Instrument.xml tags
Tag    Description
dynamic-inst    The first tag of the dynamic instrumentation configuration file. J2EE: mandatory
ISAPI: mandatory
enable    Enables or disables the instrumentation filter globally. J2EE: optional
ISAPI: optional Values: true, false Default value: true
handle-js*    Enables or disables the JavaScript handling by the filter. J2EE: optional
ISAPI: optional Values: true, false Default value: true
strict-servlet-api (J2EE)    Forces compatibility with the J2EE servlets specifications. J2EE: optional
ISAPI: not applicable Values: true, false Default value: true
js-mime-type    Uses js-mime-type protocol. J2EE: optional
ISAPI: optional
Values: if possible to use dynamically obtained, otherwise use application/x-javascript
Default value: if possible use dynamically obtained, otherwise use application/x-javascript

...