Web container custom properties

You can configure name-value pairs of data, where the name is a property key and the value is a string value that you can use to set internal system configuration properties. Defining a new property enables you to configure a setting beyond that which is available in the administrative console. The following is a list of some of the available Web container custom properties.

To specify Web container custom properties:

  1. In the administrative console click Servers > Application Servers > server_name > Web Container settings > Web Container
  2. Under Additional Properties select Custom Properties.
  3. On the Custom Properties page, click New.
  4. On the settings page, enter the name of the custom property that you want to configure in the Name field and the value that you want to set it to in the Value field.
  5. Click Apply or OK.
  6. Click Save on the console task bar to save your configuration changes.
  7. Restart the server.

Following is a list of custom properties provided with the Application Server.

[Updated in July 2011]

Changing how a JSP handles the <tsx:repeat> syntax

Use this custom property to facilitate the migration of Version 5.1 applications.

[Updated in August 2011] In Version 5.0 of the product, the index attribute of the <tsx:repeat> tag was of the type primitive integer. The index attribute of the <tsx:repeat> tag is now of the type java.lang.Integer. If you are migrating applications, from Version 5.1 of the product, and those applications include JSPs that assume that the index attribute of the <tsx:repeat> tag is of the type primitive integer, adding this property to your web container settings and setting this property to true enables the JSP compiler to properly compile these applications. [Updated in August 2011]

aug2011

When this property is added to your web container settings, and set to true, this functionality is enabled for all applications in the server. If you want to enable this functionality for a specific application, specify the JSPAttribute 'useRepeatInt' for that specific application.</tsx:repeat></tsx:repeat>

Name Default value
com.ibm.wsspi.jsp.userepeatint false
[Updated in July 2011]
jul2011

Changing the file lock time for a JSP [Fix Pack 23 or later]

Use the com.ibm.ws.jsp.zosFileLockRetrying property to specify, in seconds, the amount of time during which a thread continues to try to obtain a lock on a JSP.

A JSP file is locked prior to the start of the compile process, and unlocked after the compile process completes. If a thread fails to lock a JSP, the thread continues to try to obtain the file lock for that JSP for up to 240 seconds. If the thread cannot obtains the lock during this time interval, an error message is issued. The thread does not make any additional attempts to obtain a lock for the JSP.

Data type Integer
Default 240

Changing the file lock time for a JSP

Use the com.ibm.ws.jsp.zosFileLockRetrying property to specify, in seconds, the amount of time during which a thread continues to try to obtain a lock on a JSP.

A JSP file is locked prior to the start of the compile process, and unlocked after the compile process completes. If a thread fails to lock a JSP, the thread continues to try to obtain the file lock for that JSP for up to 240 seconds. If the thread cannot obtains the lock during this time interval, an error message is issued. The thread does not make any additional attempts to obtain a lock for the JSP.

Data type Integer
Default 240

Changing the maximum number of parameters allowed in an inbound request [Fix Pack 43 or later]

You can use the com.ibm.ws.webcontainer.maxParamPerRequest custom property to change the maximum number of parameters allowed in your inbound requests, based on your applications and environment. The maximum number of parameters allowed per inbound request (GET or POST) defaults to 10000.

You can set this property to -1 if you do not want to limit the number of parameters that can be included in a request.

Name Default value
com.ibm.ws.webcontainer.maxParamPerRequest 10000

Changing the number of times that a thread attempts to compile a JSP [Fix Pack 23 or later]

Avoid trouble Avoid trouble: This custom property was added to the product in Version 6.1.0.23gotcha

Use the com.ibm.ws.jsp.zosReCompile property to specify how many times a thread should attempt to lock a JSP.

After a thread obtains the lock for a JSP, the thread determines whether the JSP is already compiled. If the JSP is not compiled, the thread tries to compile the JSP.

If after the specified number of tries, the thread cannot compile the JSP, an error message is issued. The thread does not make any additional attempts to compile the JSP.

Data type Integer
Default 5

Changing where the ServletContext.getRealPath() Java Servlet API looks for a requested resource [Fix Pack 43 or later]

The ServletContext.getRealPath() Java Servlet API does not return the correct path for a requested resource when the resource exists in an extendedDocumentRoot path and does not exist in the installed application path. If you want the ServletContext.getRealPath() Java Servlet API to look for the requested resource in the extendedDocumentRoot path if the resource is not found in the installed application path, set the com.ibm.ws.webcontainer.checkEDRinGetRealPath custom property to true.

When this property is set to true, and the requested resource is also not found in the extendedDocumentRoot path, a null value is returned.

Name Default value
com.ibm.ws.webcontainer.checkEDRinGetRealPath false

Declaring the same tag variables in a JSP If-Else condition

[Fix Pack 37 or later] The code generated for a JSP file assumes that the same tag variables are to be declared two or more times in an If-Else condition even if the variable had a 'page' scope. The custom property com.ibm.wsspi.jsp.usescriptvardupinit is used to enable this feature for all the applications deployed on a particular server. If the compatibility feature is required only for a specific application, then the JSP attribute useScriptVarDupInit needs to be enabled. If both the options are set then the JSP attribute takes preference over the web container custom property.

Avoid trouble Avoid trouble: For Version 6.1.0.35 or earlier, the code generated for a JSP file assumes that the same tag variables are to be declared two times in an If-Else condition even if the variable had a 'page' scope.gotcha
Name Value
com.ibm.wsspi.jsp.usescriptvardupinit true

Ensuring inbound requests are encoded and decoded correctly [Fix Pack 47 or later]

When the inbound request URI is not UTF-8 encoded, but the request encoding is set to UTF-8, characters whose encoded values are different in ISO-8859 are displayed incorrectly in the response. For example if the request is sent via Microsoft Internet Explorer, the characters are displayed as n-tilde characters. To ensure the characters are encoded and decoded correctly based on the request encoding set, add the com.ibm.ws.webcontainer.decodeParamViaReqEncoding Web container custom property to your Web container settings and set it to true

Name Value
com.ibm.ws.webcontainer.decodeParamViaReqEncoding false

Using MutualAuthCBindCheck for transport channels

Use the MutualAuthCBindCheck property to specify whether or not a client certificate should be resolved to a SAF principal. If this property is set to true, all SSL connections from a browser must have a client certificate, and the user ID associated with that client certificate must have RACF CONTROL authority for CB.BIND.servername. Regardless whether client certificate authentication is being used in a SSL connection or not, if these conditions are not met, the connection will be closed. Issue the following RACF command to give the user ID associated with that client certificate RACF CONTROL authority:

PERMIT CB.BIND.<optional SAF profile prefix>.clustername CLASS(CBIND) ID(clientCertUserid) ACCESS(CONTROL)
Data type String
Value true or false
Default false
Important: You can use HTTP transports on a V5.1 node in a mixed WebSphere Application Server environment. See HTTP transport custom properties for a description of these properties. However, you must use HTTP transport channels instead of HTTP transports to handle your HTTP requests on all of your other nodes. See HTTP transport channel custom properties for a description of the custom properties that you can specify for an HTTP transport channel.

Global settings for internal servlets

Web application archive (WAR) files that are packaged using third-party tools cannot specify behavior for the services that are exposed by the Web container internal servlets. You can globally enable and disable internal servlets for all Web applications at the Web container level by creating name-value pairs such as:

Name Default
fileServingEnabled true
directoryBrowsingEnabled false
serveServletsByClassnameEnabled true
For transitioning users [Fix Pack 15 or later] For transitioning users: The default value changed to false.trns

Settings that are defined in an assembly tool take precedence over the global settings that are set through the custom properties at the Web container level.

Web application deployment extensions continue to hold configuration information for the services that are provided by the internal servlets, and take precedence over the global settings that are set through the custom properties at the Web container level.

You must define unique values for the host and port on each application server. You cannot define the values of host and port as wild cards denoted by the asterisk symbol (*) when you enable the optimized communication between the Web services application and the Web container. Using wild cards indicate that the local Web container can handle Web services requests for all destinations.

Disallow the use of the serving servlets by class name

When the serveServletsByClassnameEnabled property is enabled, it is possible to access servlets directly, resulting in a possible security exposure. Define the following custom property to disallow the use of the serveServletsByClassnameEnabled property across the entire application server level.

Name Value
com.ibm.ws.webcontainer.disallowserveservletsbyclassname true

Defining classes that cannot be served by class name

The com.ibm.ws.webcontainer.donotservebyclassname custom property specifies a list of classes that cannot be served by the class name.

Name Value
com.ibm.ws.webcontainer.donotservebyclassname A semi-colon delimited list of classes to be completely disallowed from being served by class name.

Enabling the Web container to determine whether an exception was issued by a servlet or a dispatched resource [Fix Pack 23 or later]

Typically, when the Web container receives an UnavailableException, it cannot determine whether the exception was issued from a servlet or a dispatched resource. Therefore, the Web container automatically marks the servlet unavailable even if it is the dispatched resource that is unavailable.

If you are running on Version 6.1.0.23 or later, and have set the com.ibm.ws.webcontainer.discernUnavailableServlet custom property to true, any UnavailableException that is issued from a dispatched resource is placed in a wrapper. This wrapper enables the Web container to determine whether the exception was issued from the servlet or a dispatched resource. If the exception is not issued by the servlet, the Web container does not mark the servlet unavailable.

The default value for the com.ibm.ws.webcontainer.discernUnavailableServlet custom property is false.

Name Value
com.ibm.ws.webcontainer.discernUnavailableServlet true

Enabling the Web container to search an application defined ExtendedDocumentRoot for a welcome file [Fix Pack 31 or later]

Typically, the first time the Web container handles a request for a static welcome page that is not a JavaServer Pages (JSP) file, the Web container does not search the ExtendedDocumentRoot for the welcome file unless the request for that welcome file is fully-qualified. If the request is fully-qualified, the Web container serves the welcome file, and the context root of the application displays the welcome file. If the request for the static welcome file is not fully-qualified, the Web container returns a 404 error, which indicates that the Web container did not fine the welcome file.

After the Web container successfully serves a welcome file, the Web container creates a mapping for that welcome file. The Web container then uses this mapping to handle future requests for the welcome file, thereby eliminating the need for subsequent requests to be fully-qualified.

If you want the Web container to always search an application defined ExtendedDocumentRoot for a welcome file, even if the request is not fully-qualified, you can add the com.ibm.ws.webcontainer.ServeWelcomeFileFromExtendedDocumentRoot custom property to your Web container settings, and set this property to true.

The default value for this property is false.

Name Value
com.ibm.ws.webcontainer.ServeWelcomeFileFromExtendedDocumentRoot false

Suppressing request headers that start with special characters [Fix Pack 25 or later]

The com.ibm.ws.webcontainer.suppressheadersinrequest custom property can be used to suppress the inclusion of request headers that start with special characters, such as "$" or "_" . Some applications do not handle request headers that start with special characters.

Name Value
com.ibm.ws.webcontainer.suppressheadersinrequest Delimited list of header prefixes to be suppressed.

Example: $WS,_WS

Replacing the content of error message SRVE0017W or SRVE0255E with a user defined string [Fix Pack 27 or later]

Error message SRVE0017W states "Web Group not found: {0}", and error message SRVE0255 states "A WebGroup/Virtual Host to handle {0} has not been defined". These messages might be returned when the application that is called to process the request serviced by IBM WebSphere Application Server is not found. You can use the com.ibm.ws.webcontainer.webgroupvhostnotfound custom property to change the text of these message to text that is more suitable for your environment.

Name Value
com.ibm.ws.webcontainer.webgroupvhostnotfound String

Example: Application not found.

UTF-8 encoded Uniform Resource Locators (URLs)

The UTF-8 encoded URL feature, which provides UTF-8 encoded Uniform Resource Locators (URLs) to support the double-byte characters in URLs is enabled by default. You can prevent the Web container from explicitly decoding URLs in UTF-8 and have them use the ISO-8859 standard as per the current HTTP specification by using the following name-value pair:

Name Value
DecodeUrlAsUTF8 false

Global configuration of servlet listeners

The servlet specification supports applications registering listeners for servlet-related events on an individual application basis through the web.xml descriptor. However, using the listeners custom property, a server can listen to servlet events across Web applications. To implement global listening, a listener is registered at the Web container level and is propagated to all of the installed and new Web applications. This global behavior of internal servlet listeners is controlled by the listeners custom property by using the following name-value pair format:

Name Value
listeners listener_class

The values for this property is a string specifying a comma separated list of listener classes. The listener supplied must implement standard listener classes from the Java Servlet API or IBM® listener extension classes.

Binary Large Object (BLOB) data type for Oracle databases

The UseOracleBLOB custom property creates the HTTP session database table using the Binary Large Object (BLOB) data type for the medium column. This property increases performance of persistent sessions when Oracle databases are used. Due to an Oracle restriction, BLOB support requires use of the Oracle's oci database driver for more than 4000 bytes of data. You must also ensure that a new sessions table is created before the server is restarted by dropping your old sessions table or by changing the datasource definition to reference a database that does not contain a sessions table. To create a sessions table using the BLOB data type, use the following name-vaule pair:

Name Value
UseOracleBLOB true

Enforcing the length limit of a session ID to 23 characters [Fix Pack 25 or later]

Newly generated session IDs are, by default, 23 characters in length, unless you use the HttpSessionIdLength custom property to specify a different maximum length for your session IDs.

When an incoming request has a session ID that is longer than the expected session ID length, and whose prefix is identical to a pre-existing session ID, the longer ID is used to return a new session. If the length of the session ID on the incoming request is significantly larger then the maximum length specified for your system, such that it exceeds the width of the ID column in the the session table column that is used in database persistence, an SQL0302 error occurs.

To prevent the occurrence of these SQL0302 errors, you can add the ForceSessionIdLengthCheck custom property to your Web container custom properties and set it to true. When this custom property is set to true, the length of a session ID cannot exceed 23 characters. If an incoming request has a session ID that is longer than 23 characters, the first 23 characters are used to return a new session.

Name Value
ForceSessionIdLengthCheck true

Ignoring fields in a query string [Fix Pack 25 or later]

When the Web container encounters an encoding character in a query string pair that is not valid, it throws an IllegalArgumentException exception and, by default, ignores the entire query string. In applications where every field in the query string is an essential resource, it might not be desirable to ignore the entire query string. If you set the com.ibm.ws.webcontainer.ignoreInvalidQueryString custom property to true, the Web container ignores query string pairs that are not valid and continues to process valid query string pairs.

Name Default value
com.ibm.ws.webcontainer.ignoreInvalidQueryString false

Improving the startup time for large applications [Fix Pack 21 or later]

The com.ibm.wsspi.jsp.disableTldSearch custom property can be used to improve application startup time. By default, when an application starts, the JSP engine searches the application installation directories for the taglib descriptor (TLD) files. This search process might increase the startup time for large applications with a large number of files and directories. To disable this search process, use the following name-value pair:

Name Value
com.ibm.wsspi.jsp.disableTldSearch true

Invoking the filter capability

You might need use a custom servlet filter with Web applications to map files from a one URI to another URI that points to a particular resource. For example, you might map URIs that start with my_company to the my_company/external directory. Without enabling the com.ibm.ws.webcontainer.invokeFiltersCompatibility custom property, the Web container does not call any custom servlet filters.

With this custom property, the Web container calls custom servlet filters before looking for welcome files. Also, if the Web container cannot find a resource, it calls the custom servlet filters before creating a FileNotFoundException exception. This change enables the Web container to verify whether the custom servlet filters modify the path to a resource.

Name Value
com.ibm.ws.webcontainer.invokeFiltersCompatibility true

Keeping the original request dispatch forward attributes when multiple forwards and subsequent includes are called [Fix Pack 45 or later]

This property specifies whether the request dispatch forward attributes of the original request are retained during the dispatching process.

Typically, when multiple forwards and subsequent includes are called for a request, the request dispatch forward attributes are changed to reflect the new request attributes on every subsequent forward. If you want the request dispatch forward attributes to always reflect the information in the original request, even when multiple forwards and subsequent includes are called, add the com.ibm.ws.webcontainer.keeporiginalpathelements custom property to your Web container settings and set it to true.

Name Default value
com.ibm.ws.webcontainer.keeporiginalpathelements false

Mapping a request to a default servlet [Fix Pack 25 or later]

To correctly map a request to a default servlet, you need to determine the proper servlet path and PathInfo values. The following table shows the affects on the Servlet Path and PathInfo values when you set the com.ibm.ws.webcontainer.enabledefaultservletrequestpathelements custom property to a true or false value.
Table 1. Servlet Path and PathInfo values
Value Servlet Path value PathInfo value
true Set to the contents of the URI after the Context Path Set to a null value
false (Default) Set to an empty string Set based on the contents of the URI after the Context Path

Normalizing request URIs [Fix Pack 23 or later]

Typically, request URI 404 errors do not occur if a request URI is submitted from a browser, because most modern browsers automatically normalizes a request URI prior to calling WebSphere Application Server. Therefore, by default, the Web container does not normalize a request URI before trying to resolve that URI to an application and servlet mapping.

A request URI, that includes /./ or /../ as part of an application context, that has not been normalized, might fail with a 404 error. Similarly, a request URI, that includes /./" or /../ as part of a servlet path, that has not been normalized, fails to match a servlet mapping, which also results in a 404 error, even though the URI is normalized prior to resolving the URI to a JavaServer Pages (JSP) or static file.

If you are running on Version 6.1.0.23, or later, you can set the com.ibm.ws.webcontainer.normalizerequesturi custom property to true, the Web container normalizes these types of request URIs.

Name Value
com.ibm.ws.webcontainer.normalizerequesturi true

Optimizing Web services client to Web container communication

To improve performance, there is an optimized communication path between a Web services client application and a Web container that are located in the same application server process. That is, an optimized communication path is available for use between the web service client and the web service provider provided that the web service client and web service provider are in the same application server. In this case, requests from the Web services client that are normally sent to the Web container using a network connection are delivered directly to the Web container using an optimized local path. The local path is available because the Web services client application and the Web container are running in the same process.

The optimized communication path cannot be used if the Web services client and Web service provider are running on different servers.

The optimized communication path is applicable to Web services clients sending requests to Web services that are in running on the same JVM. The optimized communication path always routes the request to a service on the same JVM. In this case, the Web service's virtual host needs to have an alias for localhost and the specific port specified. For example, if you want a Web services client to send a request to a Web service available at an endpoint URL, such as http://localhost:9080/Hello/HelloWorldService and use the optimized communication between client and service, then in addition to enabling the property (setting enableInProcessConnections = true), you would have to create an alias for "localhost" and "9080" for the virtual host that the Web service is using.

The Web services client uses the defined virtual host information to determine whether the request can be served by the local Web container. You must define unique values for the host and port on each application server. You cannot define the values of host and port as wild cards denoted by the asterisk symbol (*) when you enable the optimized communication between the Web services application and the Web container. Using wild cards indicate that the local Web container can handle Web services requests for all destinations.

This optimized communication path is disabled by default. Before enabling this property, make sure that you are not using wild cards for host names in your Web container end points and make sure that wild cards are not specified for the Web container ports. Use specific ports for the web container when the optimized communication path is enabled. To enable the optimized communication path, use the following name-value pair:

Name Value
enableInProcessConnections true

You can enable the local communication path with the enableInProcessConnections custom property.

See article, Web services client to Web container optimized communication, for additional information. Set this property to true in the Web container to enable the optimized local communication path. When disabled, the Web services client and the Web container communicate using network transports.

Preventing a 401 error code, set as a result of the security check, from being replaced with a 404 error code [Fix Pack 23 or later]

When a request is received for a static file which does not exist, the Web container calls defined servlet filters. If the filters do no successfully complete, a 404 error code is set. In a situation where application security is enabled, a security check is performed as part of filter invocation. Typically if the security check fails the Web Container considers the filters to have failed and still sets a 404 error code instead of the 401 error code that indicates the failure of a security check. The 404 error code enables the requester to access the static file without logging on.

If you are running on Version 6.1.0.23, or later, you can set the com.ibm.ws.webcontainer.assumefiltersuccessonsecurityerror custom property to true, to prevent the 401 error code from being replaced with a 404 error code, and thereby ensure that a user must enter a valid userid and password before he can access a static file. The default value for this property is false.

Name Value
com.ibm.ws.webcontainer.assumefiltersuccessonsecurityerror true

Propagating an exception back to the dispatch caller resource [Fix Pack 37 or later]

When a JavaServer Page (JSP) file contains a compilation error, the runtime error is caught and handled directly by the container. Exceptions are not propagated and addressed by the dispatched JSP resource. With the com.ibm.ws.webcontainer.dispatcherRethrowSError custom property, exceptions are propagated back to the dispatched JSP resource.

By default, this custom property value is set to false.

Name Value
com.ibm.ws.webcontainer.dispatcherRethrowSError true

Using Uniform Resource Locators (URLs) without leading front slashes ( / )

WebSphere® Application Server 5.x accepts Uniform Resource Locators (URLs) without leading front slashes ( / ) and to preserve compatibility, You can set the custom property, prependSlashToResource to true. To ignore the specification and consider URLs without the leading front slash, use the following name-value pair:

Name Value
prependSlashToResource true

HTTPS requests with an SSL offloader

The custom property httpsIndicatorHeader manages HTTPS requests that are forwarded to an application server from an SSL offloader that is used in front of WebSphere Application Server. When an HTTPS request is received by a SSL offloader it is redirected over HTTP to an application server using WebSphere Application Server. The SSL offloader adds a header indicating the original request was over HTTP. The httpsIndicatorHeader property specifies the header name added by the SSL box. The application server checks this indicator to determine if SSL is required. If it determines the request is SSL over HTTP, an HTTPS scheme is chosen.

Name Value
httpsIndicatorHeader Request header key name

Using the session ID that is sent from a browser to preserve session data

The custom property HttpSessionIdReuse determines whether the session manager can use the session ID sent from a browser to preserve session data across Web applications that are running in an environment that is not configured for session persistence. In a multi-JVM environment that is not configured for session persistence setting this property to true enables the session manager to use the same session information for all of a user's requests even if the Web applications that are handling these requests are governed by different JVMs. The default value for this property is false. To enable the session manager to use the session ID sent from a browser to preserve session data across Web applications that are running in an environment that is not configured for session persistence, use the following name-value pair:

Name Value
HttpSessionIdReuse true
In a z/OS system that includes multiple servants, on rare occasions two requests come in at approximately the same time, and are routed to two separate servants. However, because the two requests come in at approximately the same time, they both request a new session with the same session ID. If the HttpSessionIdReuse property is set to true when this situation occurs, the following error message is logged for one of the servants, and the servant where the message is logged does not get a session:
ExtendedMessage: BBOO0220E: SessionContext:createSession - call to
establishAffinity for id id_number failed with rc 4".

Returning the port number from the request host header first

The getServerPort method relies on the getVirtualPort method of the channel, which returns a port number in the following order:
  1. Port number from the request URL
  2. Port number from the request host header
This order is compliant with HTTP/1.1 RFC but not with the Java Servlet Specification Version 2.4 API, which requires the port number from the host header to be returned first, if any, or the request URL. The correct returned URL for the above example is: http://ProxyServer:8888. The Web container was modified to return a port number from the host header, if any, or the URL port that accepted the client connection. You must set the trusthostheaderport and the com.ibm.ws.webcontainer.extractHostHeaderPort custom property to true to return the port number from the request host header first. For example, set these properties in the web.xml file using:
trusthostheaderport = true     
com.ibm.ws.webcontainer.extractHostHeaderPort = true

Or you can set these properties as Web container custom properties in the administrative console using the following two sets of name-value pairs:

Name Value
com.ibm.ws.webcontainer.extractHostHeaderPort true
trusthostheaderport true

Compiling functions that contain an expression

The JSP translation code was modified to handle escape characters and quotations properly when determining whether to evaluate an expression or to treat it as a literal string. To apply this behavior globally across all Web applications, add the following name-value pair as a Web container custom property:

Name Value
com.ibm.wsspi.jsp.evalQuotedAndEscapedExpression true
To enable this new behavior for a single application, you must also add the evalQuotedAndEscapedExpression JSP attribute to the ibm-web-ext.xmi file of the failing application and set the value to true. An example entry is:
<jspAttributes xmi:id="JSPAttribute_1"
name="evalQuotedAndEscapedExpression" value="true"/>
The attribute id value must be unique.

Providing HTML-formatted error page [Fix Pack 35 or later]

Typically, the Web container encodes the specified error messages prior to formatting them, to prevent Cross-Site Scripting (XSS) attacks on the client if the application does not sanitize these messages. However the the Java Servlet Specification for the sendError(int, String) method, indicates that the server should create the response to look like an HTML-formatted server error page.

If you do not want the Web container to encode the specified error messages prior to formatting them, add the com.ibm.ws.webcontainer.setUnencodedHTMLinsendError custom property to your Web container configuration settings, and set the property to true.

The default value for this property is false.

Name Value
com.ibm.ws.webcontainer.setUnencodedHTMLinsendError true

Returning an empty string for actions not set in a JSP file

If a JSP file contains an action and that property has not been set, the JSP engine returns null. In Version 5.1 an empty string was returned. This custom property was added to provide backwards compatibility. When it is set to true, the value returned on a call to jsp:getProperty is an empty string instead of null.

Name Value
com.ibm.ws.jsp.getParameterReturnEmptyString true

Setting the JDK source level through the administrative console

A JSP engine parameter can be configured for different levels of JDK, but this requires that you set the jdkSourceLevel JSP attribute in the Web extension file for each Web module. However, you can use the com.ibm.ws.jsp.jdkSourceLevel custom property to set the JSP attribute globally using the Web container custom property. If this attribute is also defined in the Web extension file, the property defined in the Web extension file supersedes the custom property for that particular application. This custom property is not case sensitive. The default value is 13.

Name Value
com.ibm.ws.jsp.jdkSourceLevel 13, 14, or 15

Recognizing filter mappings to "*" as a mapping to "/*"

When processing a request, the Web container recognizes servlet mappings to "*" as the same as servlet mappings to "/*". To provide the same behavior with filter mapping, set the com.ibm.ws.webcontainer.mapFiltersToAsterisk custom property to true. Setting the com.ibm.ws.webcontainer.mapFiltersToAsterisk custom property to true causes the Web container to recognize filter mappings to "*" as a filter mapping to "/*" . This custom property is not case sensitive.

Name Value
com.ibm.ws.webcontainer.mapFiltersToAsterisk true

Searching for exception-type before the error-code for exceptions

When an exception occurs, the Web container searches for an error page to handle that exception. The default searching order is:
  1. Any matching error-code error page
  2. Any matching exception-type error page
The matched error-code page is always returned even if there is also a matching exception type error page defined in the web.xml file. To have the Web container search and use the exception-type before the error-code, use the following name-value pair:
Name Value
com.ibm.ws.webcontainer.enableErrorExceptionTypeFirst true

Disabling file serving on all applications on a specific application server

You can enable file serving on a global level across a given application server by using the fileServingEnabled custom property. However, the fileServingEnabled property is overridden by the specific deployment information of each application. Therefore,, the current fileServingEnabled custom property only applies as a backup in case an application does not define the fileServingEnabled setting itself. To globally override this setting on a specific application server to prevent the application server from serving static files regardless of their individual deployment settings, set the Web container custom property com.ibm.ws.webcontainer.disallowAllFileServing to true to by using the following name-value pair:

Name Value
com.ibm.ws.webcontainer.disallowAllFileServing true

Writing chunks of data using synchronous writes

By default, the Web container uses asynchronous writes to write response data in chunks of up to the response buffer size. For larger responses that are greater than the response buffer size, the Web container continues to buffer response data into memory while waiting for an asynchronous write of a response data chunk to complete. This can result in part of a large response held in memory, which can lead to high memory usage and potentially an out of memory error. An application server hang may also occur when a server is simultaneously processing more requests than Web container defined threads.

If the com.ibm.ws.webcontainer.channelwritetype property is set to sync, synchronous writing is used, otherwise asynchronous writing is used by default. With synchronous writing, response data are written synchronously in chunks of up to the value of responsebuffersize and no response data are buffered into memory while waiting for a synchronous write of a response data chunk to complete. As a result, the approximate maximum amount of response data that is held in memory is equal to the responsebuffersize * number of Web container threads. The maximum number of requests that can be processed simultaneously by the Web container is limited by the number of Web container threads. Additional requests are queued, waiting for a request that is in process to complete.

The responsebuffersize Web container custom property defines the maximum amount of response data written by the Web container in a single chunk, and is 32k by default. As a result, it is used to change the number of writes needed by the Web container to send complete response data. However, if an application flushes response data, any response data held by the Web container is immediately written irrespective of the responsebuffersize.

Use the following name-value pair to write chunks of data using synchronous writes.

Name Value
com.ibm.ws.webcontainer.channelwritetype sync

Invalidating sessions after specified time has elapsed

The ForceSessionInvalidationMultiple custom property indicates whether the session manager should wait indefinitely for a request to complete before attempting to invalidate the session, or attempt to invalidate a session after the specified time limit has elapsed. The default value for this property is 1.
  • If you specify 0 (zero) for this custom property, the session manager waits indefinitely until a request is complete before attempting to invalidate the session.

    If your requests normally are not bound by a response time limit, specify 0 for this property.

  • If you specify a positive integer, such as 1, 2, or 3 for this custom property, even if a session is not known to have completed, the session manager attempts to invalidate the session if the indicated time period since the last access occurred has elapsed. This time period is the result of multiplying the value specified for this property and the value specified for the Session Timeout property. For example, if you specify 2 minutes for the Session Timeout property and 2 for the ForceSessionInvalidationMultiple property, the session manager attempts to invalidate the session after 4 minutes.

    If you want to invalidate your sessions after a certain amount of time has elapsed, specify the appropriate positive integer for this property.

Name Value
ForceSessionInvalidationMultiple 1

Sending error page exception messages to the error log file

Typically, when a recursive error occurs in an application, the trace audit method sends the resulting exception message to the z/OS® system console. Because these messages are informational messages, and no response action is required, you might want this type of message sent to the error log file instead of to the z/OS system console.

You can set the com.ibm.ws.webcontainer.divertrecursiveexceptiontoerrorlog Web container custom property to true if you want to have error page exception messages sent to the error log file instead of to the z/OS system console.

Name Value
com.ibm.ws.webcontainer.divertrecursiveexceptiontoerrorlog true

Convert start and end attributes of the repeat tag to strings

Set the com.ibm.wsspi.jsp.convertAttrValueToString Web container custom property to true to convert start and end attributes of the repeat tag to strings before they are used.

Name Value
com.ibm.wsspi.jsp.convertAttrValueToString true

Disable the commons-el expression cache

Set the com.ibm.wsspi.jsp.disableElCache Web container custom property to true to disable the commons-el expression cache if you are experiencing out of memory conditions because the hash maps are held by the expression evaluator.

Name Value
com.ibm.wsspi.jsp.disableElCache true

Create a FileNotFoundException exception when a JSP file is not found

Set the com.ibm.ws.webcontainer.throwMissingJspException Web container custom property to true When set to true, a FileNotFoundException is created when a resource included by a JSP file is missing. If this property is not set to true, an error page is displayed.

Name Value
com.ibm.ws.webcontainer.throwMissingJspException true

Extending the wait time when two servants need to concurrently compile the same JSP

When JavaServer Pages files (or user-defined JSP files) are complied in an environment that has multiple servants, the JSP container uses locking to prevent both servants from trying to concurrently compile the same JSP file. If two requests for a JSP need to be compiled at the same time, and are routed to separate servants, the JSP container locks the JSP file until the compilation for the first servant completes. If the second servant has to wait for more than 120 seconds for the lock to be released, the request for the JSP fails.

If you expect the compilation time for any of your JSP files to be more than 120 seconds, specify, in seconds, a value greater than 120 for the com.ibm.ws.jsp.zosFileLockRetrying custom property. The new setting should extend the wait time, such that the new wait time prevents a JSP request from failing in situations where two requests for the same JSP file need to be handled at approximately the same time, but the requests are routed to different servants.

Name Default value
com.ibm.ws.jsp.zosFileLockRetrying 120 seconds

com.ibm.ws.webcontainer.suppressServletExceptionLogging

If a servlet creates an exception, it is logged in the systemErr log file. For some applications, this is undesirable as it may fill up the log. In WebSphere Application Server Version 5, servlet exceptions are created but they are not logged in the systemErr log file. Beginning with WebSphere Application Server Version 6.0.2, all servlet exceptions are logged. You can use the following custom property to specify that the Web container does not log the servlet exceptions that are created in the systemErr file:

Name Value
com.ibm.ws.webcontainer.suppressServletExceptionLogging true

com.ibm.ws.webcontainer.throwfilenotfounderrorreport [Fix Pack 41 or later]

After a static file is requested, served, and deleted in the server, the next request to the file receives an empty response with a 404 status code. If you set this custom property to true, the request returns an exception with a 404 status.

Name Value
com.ibm.ws.webcontainer.throwfilenotfounderrorreport true

The default value is false.

com.ibm.ws.webcontainer.fileWrapperEvents

In WebSphere Application Server Version 5.1 processing of static files is performed by SimpleFileServlet which generates both SMF and PMI data. In Version 6.0.1, static files are handled by a file wrapper that does not generate SMF and PMI data for static files. Specify the following custom property to generate SMF and PMI data when serving the static files.

Name Value
com.ibm.ws.webcontainer.fileWrapperEvents true

Rerouting recursive error exceptions to the error log

When a recursive error occurs in an application, the exception message is logged by the trace audit method, which directs the message to the system console. However, the message needs to be logged in the error log instead. The Web container code was modified to redirect the exception message to the error log. Set the following Web container custom property to true to redirect an error exception page to the error log.

Name Value
com.ibm.ws.webcontainer.divertrecursiveexceptiontoerrorlog true
[Updated in February 2012]

Suppressing File Not Found Exceptions

When a file that does not exist and is the target of a request dispatcher include or forward operation, a FileNotFoundException occurs. When this property is set to true, this exception is suppressed as well as any logging of the failure. Also, if such a request results in a 404 exception, FFDCs are no longer created. You enable this file not found exception behavior by setting this custom property to true.

The default value is false.

Name Value
com.ibm.ws.webcontainer.modifiedFileNotfFoundExceptionBehavior false
[Updated in February 2012]
feb2012

Handling If-Modified-Since timestamps [Fix Pack 39 or later]

When the com.ibm.ws.webcontainer.ModifiedSinceLaterThanFileTimeStamp custom property is set to true, the web container returns a 304 response if the If-Modified-Since timestamp of the requested variant is newer than the timestamp of the target variant.

The default value is false.

Name Value
com.ibm.ws.webcontainer.ModifiedSinceLaterThanFileTimeStamp true

Invoke global session listeners

If a system application is the first to start, and the application attempts to load a global listener in a shared library that is associated with the server classloader, the application does not load that listener and prevents the listener from being loaded or invoked by a later non-system application. Set the com.ibm.ws.webcontainer.disableSystemAppGlobalListenerLoading custom property to true to prevent system applications from loading global listeners. When this property is set to true, the system application does not attempt to load the global listeners and later non-system applications can load them from a shared library associated with a server class loader.

Name Value
com.ibm.ws.webcontainer.disableSystemAppGlobalListenerLoading true

Controlling active request completion time

By default, when an application is stopped the Web container waits up to 60 seconds for each active request for a resource of that application to complete. You can now define the com.ibm.ws.webcontainer.ServletDestroyWaitTime Web container custom property to control the amount of time that the Web container waits for an active request to complete when the owning application is stopped.

Set the com.ibm.ws.webcontainer.ServletDestroyWaitTime custom property to an integer value, which specifies the number of seconds to wait for a request to complete. The default value is 60 seconds.

Name Value
com.ibm.ws.webcontainer.ServletDestroyWaitTime integer

modifyPageContextVariable

During the translation phase of a tag file that is compiled, the JSP container implicitly uses the pageContext variable for the PageContext object. The use of the pageContext variable as an implicit variable name in tag files does not comply with the JSP Specification.

If compilation errors occur for applications that use a local pageContext variable in their tag file, set the com.ibm.wsspi.jsp.modifyPageContextVariable custom property totrue to remove the use of the pageContext variable name in the generated Java code for tag files.

Name Value
com.ibm.wsspi.jsp.modifyPageContextVariable true

Make query string available to the welcome file [Fix Pack 25 or later]

Typically, when a request is initially sent to the context root of the application, the request is forwarded to a welcome file. If a query string is included in an initial request, it is not available to the welcome file if you included the request.getQueryString() attribute in the welcome file. However, the query string is available to the welcome file if you included the javax.servlet.forward.query_string attribute in the welcome file.

If you need to use the request.getQueryString() attribute, instead of the javax.servlet.forward.query_string attribute, to make the query string available to the welcome file, add the com.ibm.ws.webcontainer.provideQStringToWelcomeFile custom property to your Web container configuration and set the property to true. The default value for this property is false.

Name Value
com.ibm.ws.webcontainer.provideQStringToWelcomeFile true

Enable the application server to use inbound private headers

The trusted custom property enables the application server to use inbound private headers from the Web server plug-in. These inbound private headers notify the application server about the connection to the Web server. When you set the custom property to true, the application server uses the asserted information on the client certificates. These client certificates are used by the end user to connect to the Web server and establish the client information, which is treated as the certificate for the end user. Then, the application server uses the certificate information for authentication purposes when client certificate authentication is used or when the application code accesses the javax.net.ssl.peer_certificates certificates. Because this information is asserted, it is insecure and potentially vulnerable to an attacker that is able to connect directly to the application server and bypass the Web server.

The default value for this property is true.

Important: If you allow direct connections to the application server and use client certificates, you need to set this custom property to false.
Name Value
trusted true

Suppressing the last zero byte chunk when there has been an error in the application [Fix Pack 27 or later]

Typically, the last zero byte chunk is used to indicate, to a client, the end of the response data in a chunked encoded transmission. Some applications use this last zero to determine when the response data is completely received, and they can start processing it. If an error occurs in the application after the response headers are sent, the last chunk of data is still sent to the client. The client might not realize that an error has occurred, and attempt to process incomplete data.

If you set the com.ibm.ws.webcontainer.suppressLastZeroBytePackage custom property to true, if an error occurs in the application after the response headers are sent, the last chunk of data is not sent to the client. The default value for this property is false.

Name Value
com.ibm.ws.webcontainer.suppressLastZeroBytePackage true

Enabling the JSP Engine to demarcate between Web fragments when no flush occurs [Fix Pack 29 or later]

The dynamic cache service uses flushes to determine when one cacheable Web fragment, such as a JSP include or a c:import, ends and the next Web fragment begins. If you set the com.ibm.wsspi.jsp.usecdatatrim custom property to true for your JSP engine, all of the white space and extra lines in the generated Java code are stripped out. In this situation there might not be any content to write before the first flush. If the generated Java code contains text or other code before the first flush then normal dynamic cache service processing occurs.

If you set the com.ibm.wsspi.jsp.usecdatatrim custom property to true, and are using the dynamic cache service, you must also set the com.ibm.ws.jsp.getWriterOnEmptyBuffer custom property to true. This custom property requires the JSP Engine to call the flush function when it reaches the end of the first cachable Web fragments even if there is not any data to flush. The default value for this property is false.

Name Value
com.ibm.ws.jsp.getWriterOnEmptyBuffer true

Setting the body content buffer size

The size of the body content buffer for a JavaServer Pages (JSP) file can affect the performance of some applications. By default, the body content buffer size is 512 bytes. However, you can use the BodyContentBuffSize custom property to set a different buffer value.

Name Value
BodyContentBuffSize 512

Reducing the size of a large body content buffer [Fix Pack 29 or later]

The body content buffer size of the tag bodies for a JavaServer Pages (JSP) file are reused to optimize performance. If the size of a tag body increases beyond the default body content buffer size, the buffer is resized to accommodate the tag body. However, the buffer is not reset to the default size after serving a request. As a result, the heap memory that is used by org.apache.jasper.runtime.BodyContentImpl implementation might increase over time. You can configure the body content buffer size by setting an integer value for the BodyContentBuffSize custom property. For more information, see Setting the body content buffer size.

Use the com.ibm.ws.jsp.limitBuffer custom property to deallocate large body content buffer sizes and create a new buffer with the default buffer size.

The default value for this property is false.

Name Value
com.ibm.ws.jsp.limitBuffer true

Customizing the content of your SMF type 120 record [Fix Pack 31 or later]

Starting with Version 6.1, the SMF type 120 record displays the name of the static resource instead of FileServletWrapper in the name field of a static file report. If you migrated to from an earlier version of the product, and want your SMF type 120 record to display FileServletWrapper in the name field of a static file report, add the com.ibm.ws.webcontainer.FileWrapperEventsLessDetail custom property to your Web container settings and set it to true. The default value for this property is false.

Name Value
com.ibm.ws.webcontainer.FileWrapperEventsLessDetail false

Blocking a Java script running in a browser from accessing a cookie [Fix Pack 31 or later]

The com.ibm.ws.webcontainer.HTTPOnlyCookies custom property provides a level of defense against a client-side script accessing a protected cookie and acquiring its content. By using this custom property you can prevent Java scripts that run in a browser from accessing all cookies or a particular list of cookies of your choosing. The HTTPOnly attribute is added to each cookie specified in this custom property and enables protection from client-side script access.
Avoid trouble Avoid trouble: Specifying com.ibm.ws.webcontainer.HTTPOnlyCookies with no operands means that the HTTPOnly attribute will NOT be added to any cookie, and any client-side Java script running in a browser can access the content of any and all cookies.gotcha
The following examples illustrate setting this custom property.
com.ibm.ws.webcontainer.HTTPOnlyCookies = *
com.ibm.ws.webcontainer.HTTPOnlyCookies =  cookieName1, Account3Cookie, JsessionID 
Note: Cookie names used in specifying com.ibm.ws.webcontainer.HTTPOnlyCookies are case-insensitive.
Name Value
com.ibm.ws.webcontainer.HTTPOnlyCookies

*         An asterisk value means that all cookies will be given the HTTPOnly attribute.

OR

          a comma delimited list of specific cookies that only will be given the HTTPOnly attribute

Enabling multiple reads of post data [Fix Pack 31 or later]

You can set the com.ibm.ws.webcontainer.enableMultiReadOfPostData custom property to true if you want to enable multiple reads of post data. When this property is set to , the post data can be read multiple times as either an InputStream or Reader, and as parameters.

When the Web container is enabled for multiple reads of post data, you can set up an application to complete the following actions if you want that application to re-read post data from the beginning using either an InputStream or Reader:
  1. Obtain the InputStream or Reader
  2. Read the data
  3. Close the InputStrean or Reader

If either the first or third action does not occur, the next read of the post data is not reset to the beginning of that data.

The Web container automatically completes this sequence if an application re-reads the post data as parameters.

The default value for this property is false.

Name Value
com.ibm.ws.webcontainer.enableMultiReadOfPostData true

Specifying a different character as the clone separator in session cookies

You can use the CloneSeparator custom property to specify a different character as the clone separator in session cookies. The value specified for this custom property must be a single character.

Best practice Best practice: This property should only be used as a means to provide more flexibility if you have a situation where you cannot use either a colon (:), or a plus sign (+) as the clone separator in session cookies. You should understand the clone character requirements of other products running on your system before using this property to change the clone separator character.

The fact that any character can be specified as the value for this custom property does not imply that the character you specify will function correctly. This fact also does not imply that IBM is responsible for fixing any problem that might arise from using an alternative character.

bprac

Enabling case insensitive security identity checks [Fix Pack 33 or later]

When a user configures session security integration, the session manager compares the security identity of th session owner with the security identity of the client request. Because the matching criteria is case sensitive, if these two identities do not exactly match, an UnauthorizedSessionRequestException is sent back to the client.

If you have situations where you want the session security identity and the client security identity to be considered a match even if their cases are different, add the SecurityUserIgnoreCase custom property to your Web container configuration settings, and set the property to true. When this property is set to true, an UnauthorizedSessionRequestException does not occur if the session security identity and the client security identity are identical except for their cases. For example, when this property is set to true, the session security identity USER1 matches the client security identities User1 and user1.




Reference topic Reference topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=rweb_custom_props
File name: rweb_custom_props.html