Complete list of WebSphere Application Server V4.0 (all releases) HTTP plug-in defects fixed
 Technote (FAQ)
 
Problem
The following is a list of all plug-in defects fixed in all releases of WebSphere® Application Server V4.0. The latest 4.0.2-4.0.7: Plug-in component cumulative fix dated Sept 16, 2004 includes all of the fixes mentioned in this document.

4.0.2-4.0.7: Plug-in component cumulative fix download:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg24001801
 
Solution
160939 - Need configuration options to disable the nagle algorithm
162288 - Domino plugin fails to load on Solaris when using Domino6
177376 - Authentication fails with Domino WebServer plugin
PQ65565 - Corrupted client certificate with iPlanet 6.1
PQ65742 - Uri matching is inconsistent between plugin processing stages
PQ67072 - Invalid error number reported on Solaris
PQ67476 - Wrong session name used for session affinity
PQ67481 - Error message in Event Viewer when Apache/IHS started
PQ67506 - Client certificates truncated by IIS
PQ67717 - Logging improvement: Adding hostname to log message
PQ67809 - Best match does not apply to virtual host matching
PQ67965 - Application server marked down on client error
PQ68139 - WCS caching library problem with plugin-cfg.xml
PQ68477 - Internal connection header being leaked to webserver
PQ69512 - Compatibility flag for virtual host matching
PQ69608 - Failover problem with proxy firewall
PQ70020 - Case sensitivity for cookie names
PQ70037 - POSTs not using keep-alive connections
PQ70292 - Error logged on incomplete POST content
PQ70620 - Virtual host matching is case sensitive
PQ70962 - Wrong status returned for IIS plugin
PQ71167 - Failure when response header exceeds 8k
PQ71223 - Log level change for "Failed to read the first line of continued response"
PQ71608 - Plugin marks the only appserver down
PQ72069 - Need configurable option for redirect port source
PQ72257 - IHS/Apache plugin not reading plugin-cfg.xml after refresh interval expires
PQ72428 - Flush request header buffer immediately to reduce chance of timeout firing
PQ73479 - Add parameter to specify the chunk size for reading the response body
PQ74834 - Update mappings for cipher suite names
PQ75936 - Add support to hanlde headers extended over multiple lines
PQ75947 - HTTP Plugin fails to load intermittently
PQ76680 - Add support to limit the number of connections to an Application Server
PQ76729 - Applications hang due to incorrect Content-Length handling
PQ76727 - Core dump in IHS/Apache SSL module
PQ77059 - Plugin does not do full match for JSESSIONID cookie
PQ77058.1 - Plugin failed to start with lots of HTTPS transports configured
PQ77261.2 - Plugin key store needs to be updated
PQ77923 - postSizeLimit not honored
PQ78702 - Down server not receiving requests after restart
PQ78948 - WAS plug-in for IHS 2 not handling session info in URI
PQ79090 - Clone ID parsing fails when multiple cookies are present
PQ80913 - IIS plug-in did not set the WAS special header having remote host information
PQ80924 - Backslash in Cookie header was not handled correctly
PQ81029 - IIS, iPlanet & Domino plug-in sent "Connection: Close" response header if there
is no "Content-Length" header in the response
PQ81125 - Cannot access appserver application through IIS/plug-in
PQ81346 - Plug-in failed to mark server down and do the failover
PQ81797 - Plug-in sent empty WAS special header having client certificate to Websphere appserver
PQ81856 - IHS 2.0 CPU usage spiked after client closed the connection
PQ82330 - AddOutPutFilterByType didn't respond to a Content-Type set by servlet
PQ82740 - IIS plug-in corrupted the POST request data
PQ82742 - RefreshInterval property in plugin-cfg.xml cannot be disabled
PQ82756 - Added new plug-in configuration option IISPluginPriority
PQ82865 - Segfault handling request after plug-in install and graceful restart
PQ83334 - Memory leak in plug-in configuration reload
PQ84704 - 500 response was received when ExtendedHandshake was set to True
PQ84704.1 - Needs to check socket status after extended handshake
PQ84887 - Plug-in did not do failover correctly
PQ86174 - error in gsk_secure_soc_close: GSK_INVALID_STATE (gsk rc = 5)
PQ86442 - Not fail on customer cookies in non-standard format
PQ86467 - iPlanet plug-in failed to parse and set headers
PQ88879 - Plug-in returned success code while failed to load new plugin-cfg.xml
PQ89583 - Plug-in marked the appserver down incorrectly
PQ92641 - Apache plug-in did not send the client SSL certificate
PQ93112 - Unclosed Connections caused plug-in performance degradation




Additional APAR information:

160939: Allow customer to enable/disable the Nagle algorithm

The Nagle algorithm for TCP makes the TCP stack delay the
writing of small packets out to the network in the hope
that the delay will allow the user program to feed it
more data so the packet can be filled out more before it
has to be released on the network. The aim is to reduce
the number of smaller packets going out to improve overall
throughput - each packet has a small amount of protocol
information attached to it, and the larger the ratio of
user data to protocol data, the better. However, this
algorithm can delay the writing of a packet for up to
200ms - a very significant delay in situations where
you are writing small chunks of data at one time.
The plugins can see this delay on small sets of request
headers, especially from 100-Continue headers. ( Which
are more common since PQ70037 introduced the use of them
in normal plugin operations ).

There are now two configration options that allow the
customer to choose to disable the Nagle algorithm. The
first controls the Nagle algorithm on the connections
that are established between the plugins and the application
server. It is a boolean attribute on the Config tag
in the plugin-cfg.xml file called "ASDisableNagle". To
turn off the nagle algorithm, you can add this attribute
to the Config tag, like so:

<Config ASDisableNagle="true">

The other configuration option is IIS specific. IIS
by default does not disable the Nagle algorithm for client
to web server connections, and does not provide a way for
users to configure this. This is also a boolean attribute
on the Config tag in the plugin-cfg.xml, named
"IISDisableNagle". To disable Nagle for IIS connections
handled by the plugins, you could add this attribute
to the Config tag like so:

<Config IISDisableNagle="true">

This only has an effect on versions of IIS prior to
6.0 - as of 6.0, the decision to disable or enable the
Nagle algorithm is up to the web services driver, http.sys.

Keep in mind that for both of these options, the
performance gains are not completely free. By disabling
the Nagle algorithm, you are in some cases increasing
the number of packets traversing your networks.


162288: Domino plugin fails to load on Solaris when using Domino6

SOLARIS ONLY!! There is a new plugin to use with Domino6
(libdomino6_http.so). The Domino6 webserver failed to load a plugin which
used GSK4. GSK5 is required for the Domino6 plugin. If using Domino5 you
should continue to use the libdomino5 plugin.


17737: Authentication fails with Domino WebServer plugin

The domino plugin failed to retrieve the client certificate from the
webserver causing authentication to fail. This fix retrieves the client
certificate from the webserver.



PQ65565: Corrupted client certificate with iPlanet 6.1

The iPlanet 6.1 plugin does not handle client certificates correctly.
Applications attempting to get client certificate details would
either get nothing at all, or would fail because the certificate
looked corrupted. PQ67506 takes care of a similar (but separate)
problem with the IIS plugin.



PQ65742: Uri matching is inconsistent between plugin processing stages.

A problem in the best match code for URI matching made it so
a request would pass a URI match in an early stage of processing,
and then turn around and fail it in later stages. For IHS, Apache,
and IIS, this could cause the plugins to attempt to handle requests
that the webserver should have been handling.



PQ67476: Wrong session name used for session affinity

Main symptom of problem: Session Affinity would not work when the user had multiple affinity cookies for the various applications they had installed.

The plugin was using the last matched url to determine the name
used for session affinity rather than the best matched url, which
can be wrong for configurations with multiple affinity cookies.



PQ67481: Error message in Event Viewer when Apache/IHS started.

The following message is logged in the Application Log Event Viewer when
Apache/IHS is started via the Services panel:

The Apache service named Apache.exe reported the following error:
[notice] Initializing the WebSphere Plugin <<< before the error.log
file could be opened.

The message is caused because APACHE calls initialization routines twice.
On the first call the error.log has not been opened. With this applied,
the plugin init routine is only executes on the second call.



PQ67506: Client certificates truncated by IIS

Exceptions would occur on the app server when trying to access the
client certificate. The exception would be:

[TIMESTAMP] bdbba2f HttpRequest X PLGN0024E: No certificates java.security.cert.CertificateException: Unable to initialize, java.io.IOException: extra data given to DerValue constructor

The plugin was truncating the client certificate before sending it over to
the application server.



PQ67072: Invalid error number reported on Solaris

The wrong OS error number was being recorded in the WebSphere plugin
traces on connect failures. The problem was due to a missing flag in the
Solaris builds which has been resolved by this fix.



PQ67717: Logging improvement: Adding hostname to log message.

Logging improvement: Changes logging for clones that
go down so it includes the hostname of the clone that could not
be contacted.



PQ67809: Best match does not apply to virtual host matching.

The best match algorithm was expanded to include the virtual host
matching. (Before, only URI matching was best match.) This is
only useful for customers with configurations where the choice
between a virtual host of "*:port" and a more specific match of
"hostname:port" should be sent to different server groups.



PQ67965: Application server marked down on client error.

When there is an error reading the POST data from a request the plugins
could treat it as an appserver error, causing the appserver to be marked down. This fix prevents this from occurring.



PQ68139: WCS caching library problem with plugin-cfg.xml

The plugin config parsing logic did not allow for the
Websphere Commerce Suite cache property (or any non transport property) to be anywhere other than the top of the file. This eliminates that limitation.



PQ68477: Internal connection header being leaked to webserver.

The plugins would pass the "Connection" header that comes back
from the application server back in the response to the client,
which can interfere with the web server's keep-alive behavior.
The "Connection" header that comes back from the application server
is meant to control the connection between the plugins and the
application server, so the plugins will no longer pass that header
through to the webserver.



PQ69512: Compatibility flag for virtual host matching

PQ62683 changed how the vhost matching works, which has caused
some configuration problems. The workaround was to manually
change the port numbers in the virtual hosts entries in the
plugin-cfg.xml file. Before PQ62683, the virtual
host matching was done against the port number that the request was
received on - after PQ62683, the vhost matching is done against the
port number that is parsed from the host header.

The latter is the intended behavior, but this APAR adds a
compatibility flag for customers who do not want to have to go
through and change the virtual host port numbers in all of their
plugin-cfg files.

The attribute that switches this behavior is the "VHostMatchingCompat"
attribute in the "Config" tag. Set it to true to get the older matching
behavior. It defaults to false if not specified.

Ex:
<Config VHostMatchingCompat="true">



PQ69608: Failover problem with proxy firewall.
****
**** THE APPSERVER SIDE COMPONENT OF PQ69608 IS NOT
**** BUNDLED WITH THIS EFIX. CUSTOMERS WISHING TO USE
**** THIS FUNCTIONALITY WOULD NEED TO APPLY PQ69608 OR
**** PLUGIN CUMULATIVE EFIX DATED 2-28-2003 ON THEIR
**** APPSERVER MACHINE

Plugin failover would not work when a proxy firewall was used. In order
to fix this some extra handshaking needed to occur between the plugin and
the app server after a successful connection to make sure the connect() was
successful. A new attribute for the Server element was created called
ExtendedHandshake and can be set to either true or false. The default value
is false. Here is an example of how to specify the new attribute:

<ServerGroup Name="default_group">
<Server Name="default_server1" ExtendedHandshake="true">
<Transport Hostname="192.168.1.2" Port="9080" Protocol="http"/>
</Server>
</ServerGroup>

This fix has to be applied to both the webserver and all of the
application servers that the plugins can send requests to, as it
changes both the plugin and the transport components. This fix is
needed by any customer who has a proxy firewall that will accept
a connection request for an application server before checking to
see if the application server is actually up.



PQ70020: Case sensitivity for cookie names

The plugin was doing a case insensitive compare for the cookie
name. This could cause problems if one app was using jsessionid
and another JSESSIONID. That sort of naming scheme cookies is
arguably bad practice, and goes against the cookie spec, in that
the cookie spec says that the cookie name should be case insensitive.
However, some browsers will treat "jsessionid" and "JSESSIONID" as separate cookies, so this fix makes the plugin perform case sensitive compares on cookie names to deal correctly with this kind of situation.



PQ70037: POSTs not using keep-alive connections
****
**** THE RELATED APPSERVER SIDE CODE IS NOT BUNDLED IN THIS FIX. SERVLET
**** ENGINE/WEB CONTAINER APAR PQ70205 AND PQ70895 SHOULD BE APPLIED ON
**** THE APPSERVER MACHINE for WAS 4.0.5 OR EARLIER RELEASES. WAS 4.0.6
**** OR LATER RELEASES ALREADY INCLUDE THIS TWO FIXES.

The plugin opens a new connection for every POST request in order to
avoid losing the POST content on a connection whose Keep-Alive timeout
has fired. To avoid losing POST data, the plugins utilize the 100 Continue
support of HTTP 1.1. This will allow persistent connections to be used
with POST requests.



PQ70292: Error logged on incomplete POST content

The plugin was logging an error message when the client failed to send the
full POST content. It was also returning error 500 to the webserver.
It now logs that message as WARN and returns error 400, to be compliant
with the HTTP/1.1 spec.



PQ70620: Virtual host matching is case sensitive

Virtual Host matching was unintentionally made case sensitive,
which is not the correct behavior. This APAR fixes it so it is
case insensitive again.



PQ70962: Wrong status returned for IIS plugin

For customers using IIS, a 200 response code was being returned
for requests that were actually return code 500, so the access
logs of the server would not correctly reflect the results of
the transaction.



PQ71167: Failure when response header exceeds 8k

The plugin would fail on writing responses which contain
a header greater than the default buffer size of 8k. Reading of
the first 8k of data would succeed however the next read would
contain the remains of the header value. Since the data was not
in the Header: Value format an invalid format header is returned.
This fix modified the plugin so that a response header of 100k
is handled. Anything larger than 100k fails with an informative
error message. (This problem was reported by customers sending
large Location headers in the response. While the plugin will
handle a 100k Location header the webserver and/or browser may not)



PQ71223: Log level change for "Failed to read the first line of continued response"

ERROR: lib_htrequest: htrequestWrite: Failed to read the first line of the continue response is logged during a race condition where the appserver can close a keep-alive connection at a point where we&apos;ve already decided to use it. The message is harmless as when this happens the failover will still ensure that the request will be served. However the message should not be getting logged as an error. This APAR changed the log level to TRACE.



PQ71608: Plugin marks the only appserver down

In versions prior to 4.0, the failover code would not mark down
the only server in a server group, as marking it down didn't really
do anything useful: there's no failover if there's only one server in the
ServerGroup, so marking the server down will at best make it take a little
bit longer for the plugins to notice when the only application server comes
back up. This APAR is to extend this behavior of not marking down the only
server in a ServerGroup to WebSphere versions 4 and above. Keep in mind
that this fix only improves our behavior in cases where there is only one server in a ServerGroup, and is not meant as a fix for servers being marked down for unknown reasons. For any situation where a server is being marked down for unknown reasons, work still needs to be done to work out why the server is being marked down, even if applying this APAR makes the symptoms less severe - the kinds of things that cause servers to be marked down randomly are usually signs of a deeper problem that needs to be addressed.



PQ72069: Need configurable option for redirect port source

Since PQ62683, the port number that the application server
uses in building URI&apos;s for a sendRedirect comes from the
host header of the request coming in. For the vast majority
of customers, this is the desired behavior, but in some
cases, the customer wants the port number that the web
server received the request on. To allow for this, a
configuration option has been added to the plugin-cfg
that allows the customer to choose the behavior.
"AppServerPortPreference" is an attribute on the "Config"
tag in the plugin-cfg.xml file, and has two valid values:
"HostHeader" - Use the port number from the Host header
"WebServerPort" - Use the port the request was received on
The default if it is unspecified is "HostHeader".
For example, if I wanted to change my plugin-cfg.xml
so we used the port number the request was received on,
then my config tag would look something like this:
<Config AppServerPortPreference="WebServerPort">
This fix should be applied on the web server machine.


PQ72257: IHS/Apache plugin not reading plugin-cfg.xml after refresh interval expires
When using IHS/Apache the plugin would not set the request time prior to checking to see if WebSphere should handle the request. This sometimes caused a delay in the reloading of an updated plugin-cfg.xml.



PQ72428: Flush request header buffer immediately to reduce chance of
appserver timeout firing

The plugin is mistakenly marking an app server down when the client
takes longer than the IOTimeout to send the POST content. The plugin should
flush the output buffer after all the headers are written to the appserver.
This will force the headers to be sent to the app server right away and
disengage the IOTimeout so the app server doesn&apos;t close the connection.



PQ73479: Add parameter to specify the chunk size for reading the response body

The plugin would read the response body in 64k chunks until all of the
response data was read. This caused a performance problem for requests with large content length. The attribute ResponseChunkSize was added so customers can set the maximum chunk size to use when reading the response.

Ex:
<Config ResponseChunkSize="N">
where N = the chunk size in kilobytes.

If the content length is unknown the response a buffer of size Nk will be
allocated and the response body will be read in Nk size chunks. If the content length is known and content length is less than N then a buffer of size content length will be allocated and the response body will be read in one chunk. If ResponseChunkSize is not specified the default size will be 64k.



PQ74834: Update mappings for cipher suite names (IHS/IPlanet/SunOne)

Because the set of possible cipher suite names vary depending
on the webserver, cipher suite names are normalized in the
plugin before being forwarded to the Application Server. This
defect corrected the mapping for
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA and
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA.

The mappings for the cipher suite names are below:
IHS LONG NAME SHORT NAME
SSL_DES_192_EDE3_CBC_WITH_MD5 DES-CBC3-MD5
SSL_RC4_128_WITH_MD5 RC4-MD5
SSL_RC2_CBC_128_CBC_WITH_MD5 RC2-MD5
SSL_DES_64_CBC_WITH_MD5 DES-CBC-MD5
SSL_RC4_128_EXPORT40_WITH_MD5 EXP-RC4-MD5
SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 EXP-RC2-MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
SSL_RSA_WITH_RC4_128_SHA RC4-SHA
SSL_RSA_WITH_RC4_128_MD5 RC4-MD5
SSL_RSA_WITH_DES_CBC_SHA DES-CBC-SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA EXP1024-RC4-SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DES-CBC-SHA

IPLANET/SUNONE LONG NAME SHORT NAME
DES-EDE3-CBC_168 DES-CBC3-MD5
RC4_128 RC4-MD5
RC2-CBC_128 RC2-MD5
DES-CBC_56 DES-CBC-MD5
RC4-Export_40 EXP-RC4-MD5
RC2-CBC-Export_40 EXP-RC2-MD5
3DES-EDE-CBC_168 DES-CBC3-SHA
RC4_128 RC4-MD5
DES-CBC_56 DES-CBC-SHA
RC4-40_40 EXP-RC4-MD5
RC2-CBC-40_40 EXP-RC2-CBC-MD5
Customers who need to know the exact cipher name in their
application should refer to the above list.



PQ75936: Add support to hanlde headers extended over multiple lines

As per HTTP/1.0 RFC1945,'http://www.w3.org/Protocols/rfc1945/rfc1945'
the header fields can be extended over multiple lines by preceding
each extra line with at least one SP or HT, though this is not
recommended. Plugin has been enhanced to support headers extended
in multiple lines.



PQ75947: HTTP Plugin fails to load intermittently.

Plugin config parser was updating an internal variable at a wrong
memory location. If the plugin doesn't have access to that memory,
it would result in memory access violation. Sometimes, GSKIT libraries
were not getting loaded because of this. This scenario has ben fixed.



PQ76680: Add support to limit the number of connections to an Application Server

Enhanced plugin so that users can set limit the number of pending
connections to an App Server using the new attribute "MaxConnections".
If the number of current pending connections reaches "MaxConnections",
then that server will not be selected. If no other servers are
selectable, the request will end with HTTP return code 503. This
feature will work well if the webservers follow
**threading model (not a process model)** and only **one** process
is started by the web server.

The following changes are to be made to have the feature fully enabled.

The plugin config file should be updated to include the attribute
"MaxConnections" for the server definition. The following is a sample
configuration.

<ServerGroup Name="PLUGINCLUSTER">
<Server CloneID="ujsv71f3" Name="myhost1_server1" MaxConnections="50">
<Transport Hostname="myhost1" Port="9080" Protocol="http"/>
</Server>
<Server CloneID="ujsvembh" Name="myhost2_server1" MaxConnections="100">
<Transport Hostname="myhost2" Port="9081" Protocol="http"/>
</Server>
</ServerGroup>

Changes to IHS 2.0 config file (httpd.conf) :

Eventhough, IHS 2.0 follows threading model, it allows more than one process to be started. Below example of changes to the httpd.conf of IHS 2.0 on Unix will ensure that only one process is started by IHS 2.0.

Example: Replace the existing block for worker.c with the following.

<IfModule worker.c>
ServerLimit 1
ThreadLimit 4000
StartServers 1
MaxClients 1024
MinSpareThreads 1
MaxSpareThreads 1024
ThreadsPerChild 1024
MaxRequestsPerChild 0
</IfModule>



PQ76729: Applications hang due to incorrect Content-Length handling

Enhanced plugin so that users can send request content on all requests
(i.e., POST, PUT, GET, HEAD) when Content-Length or Transfer-encoding
header is contained in request header. The default behavior will be to
expect and read content for POST and PUT requests only. To enable this
feature the plugin-cfg.xml must be updated to contain the AcceptAllContent
property. Example: <Config AcceptAllContent="true">



PQ76727: Core dump in IHS/Apache SSL module

Apache/IHS plugin returned wrong code to Web server when an early client
close occurred. The plugin should return DONE to Web server indicating
that there is nothing more for IHS to do. Returning anything other than
DONE in this case could lead to extra processing that will cause the SSL
module to segfault.



PQ77059: Plugin does not do full match for JSESSIONID cookie

When JSESSIONID and JSESSIONID_302 are used for two different session IDs, plugin only matches the beginning part of the cookie name for session affinity. This could result in the wrong session id. Now plugin performs full match for JSESSIONID cookie.



PQ77058.1: Plugin failed to start with lots of HTTPS transports configured

Plugin module failed to load when there were lots of HTTPS transports
configured. The GSKIT library is only loaded once now to avoid this problem.



PQ77261.2: Plugin key store needs to be updated

Plugin is enhanced to pick up the new key store.



PQ77923: postSizeLimit not honored

Plugin is enhanced to honor the value of postSizeLimit specified in the
plugin-cfg.xml file. If no value is specified, there should not be any limit
on the post size.



PQ78702: Down server not receiving requests after restart

After a downed server was restarted the plug-in was not sending requests to
the server. This issue only occurred when load balance weights were used.



PQ78948: WAS plug-in for IHS 2 not handling session info in URI

URLs to be served by WebSphere Application Server that contain a ":" in
the parameter list (e.g. 'http://127.0.0.1:8080/foo;session=0:0') will be
rejected by IBM HTTP Server v2.0 with either a 403 or 404 status code and
not be forwarded to WebSphere Application Server. URLs of this form were
accepted by IBM HTTP Server version 1.3.



PQ79090: Clone ID parsing fails when multiple cookies are present

When additional cookie is added, plug-in fails to do session affinity, and
plug-in picked up wrong session information when both jsessionid and
JSESSIONID were used in Cookie header.



PQ80913: IIS plug-in did not set the WAS special header having remote host information

Websphere plug-in for IIS did not set and forward WAS special header
having remote host information to the application server.
Plugin-in is enhanced to compute the remote host information using
the enviroment variable REMOTE_HOST. The environment variable REMOTE_ADDR is used if there is no REMOTE_HOST information.



PQ80924: Backslash in Cookie header was not handled correctly

WebSphere plug-in for iPlanet did not correctly handle backslash character
in Cookie header of the HTTP request. For example, if Cookie is set to
alpesh=alpesh\alpesh in the incoming request, plug-in forwarded Cookie
value as alpesh=alpesh\\alpesh to appserver.



PQ81029: IIS, iPlanet & Domino plug-in sent "Connection: Close" response header if there is no "Content-Length" header in the response

When sending the response to the client, the plug-in was not chunking the
response even though the application set the "Transfer-Encoding: Chunked"
header in the response. Since the webserver did not receive the
Transfer-Encoding or the Content-Length header, the connection was closed
after the response was received and keepalive was not honored.

The attribute ChunkedResponse has been added for the Config element. When
ChunkedResponse is set to true in the plugin-cfg.xml, the plug-in will
chunk the response to the client if "Transfer-Encoding : Chunked" response
header is present in the response. The ChunkedResponse attribute applies
to the following webservers: IIS, iPlanet, and Domino. IHS and Apache
webservers automatically handle the chunking of the response to the client.

For example:
<Config ChunkedResponse="True">

By default the value of the ChunkedResponse attribute is FALSE.



PQ81125: Could not access appserver application through IIS/plug-in

When accessing a Websphere application through IIS/plug-in, and if this
application then sent the request to another WAS application through
IIS/plug-in, 404 (Not Found) status was returned. This problem was caused
by sending the internal headers set within IIS plug-in.



PQ81346: Plug-in failed to mark server down and do the failover

Websphere plug-in did not mark the server down when the secure stream
could not be created due to closed connection. This behavior would affect
the plug-in to do the right failover.



PQ81797: Plug-in sent empty WAS special header having client certificate to Websphere appserver

Websphere plug-in for IIS sent an empty WAS special header having client certificate to appserver when the client certificate information is not available. This has been fixed so that the WAS special header is not sent to the appserver when there is no certificate information.


PQ81856: IHS 2.0 CPU usage spiked after client closed the connection

For IHS 2.0, Websphere plug-in set the request status code according to the
response code from appserver. When client closed the connection before
plug-in sent all the response, the request status code should be reset to
indicate the error to webserver. Otherwise, a loop in IHS would be triggered.



PQ82330: AddOutPutFilterByType didn&apos;t respond to a Content-Type set by servlet

Plug-in failed to handle AddOutputFilterByType when Content-Type is set by a servlet.


PQ82740: IIS plug-in corrupted the POST request data

When IIS plug-in handled POST requests and forwarded the requests data to the application server, it sometimes corrupted the request data. The problem was caused by reading and forwarding a chunk of data multiple times.


PQ82742: RefreshInterval property in plugin-cfg.xml cannot be disabled

The plug-in now allows the user to disable RefreshInterval in the plugin-cfg.xml file. If RefreshInterval is set to -1 in the plugin-cfg.xml file, the plug-in will NOT reload the plugin-cfg.xml file. The user would have to restart the Web server in order for any changes in the plugin-cfg.xml to be picked up.


PQ82756: Added new plug-in configuration option IISPluginPriority

Customers using third-party plug-in along with WebSphere Application Server plug-in may
experience problems with the third-party plug-in. This may be due to the fact that WebSphere Application Server&apos;s plug-in runs on a higher priority than the third-party plug-in.

New plug-in configuration option IISPluginPriority was added to allow the user to specify the priority of which IIS Web server loads the WAS plug-in. Valid values are High, Medium and Low. The default priority is High.

NOTES:

** This value is used during IIS Web server startup. User MUST restart Web server for this
change to take effect.

** The default value for IISPluginPriority is High. The default value of High ensures that all
the requests are handled first by the WebSphere Web server plug-in before other
filters/extensions. If customer experiences problems running the WAS plug-in at Medium or Low they would need to rearrange the order or change the priority of the interfering filter or extension.


PQ82865: Segfault handling request after plug-in install and graceful restart

During startup (apachectl start) of IHS/Apache the initialization routine is called twice. The
plug-in "passes" on the first initialization and is fully initialized on the second call. During server restart (apachectl restart) the initialization routine is only called once. In the case where the plug-in is not configured during the initial start of the Web server, issuing the
restart command will not cause the plug-in to load (since plug-in initialization will pass on the
first call to the initialization routine). The Web server will start successfully however any
request sent to the Web server will cause the Web server to crash.

This fix detects whether the initialization routine is called as a result of a restart. If so,
then full plug-in initialization will occur thus preventing the crash.


PQ83334: Memory leak in plug-in configuration reload

When there were HTTPS transports configured in plugin-cfg.xml, memory usage growth was seen after each plug-in configuration reload. This is because the memory used to set up SSL environment for each HTTPS transport was not freed when the new plug-in configuration was loaded, and the new SSL environments were set up.


PQ84704: 500 response was received When ExtendedHandshake was set to True

Plug-ins are the preferred method of communication between the Web server and the application server. However, when a proxy server is used between plug-in and application server, plug-in cannot make direct connection to the application server. Therefore, plug-in cannot always do failover correctly because it has no knowledge on the proxy server and cannot tell the correct application server status. To provide a workaround, after connection is established, extended handshake is performed by sending bogus request to application server and verifying response. Plug-in will mark the application server down and fail over to another application server if it receives unexpected response.


PQ84704.1: Needs to check socket status after extended handshake

This is related to PQ84704. When proxy server is used between plug-in and application server, no direct connection is made between plug-in and the application server, and persistent connection is not always used between plug-in and the proxy server. Plug-in has to check and verify the connection used for extended handshake request is still good for real client request. If the connection has been closed by remote peer, plug-in establish a new connection.

**NOTE** With a proxy server used between plug-in and application server, and ExtendedHandshake is set to "True", it&apos;s expected that it takes longer for plug-in to process a incoming request.


PQ84887: Plug-in did not do failover correctly

Persistent connections are used between plug-in and application server. When a newly-established connection is closed by application server in the middle of a request, plug-in will mark the server down and fail over to another application server.


PQ86174: error in gsk_secure_soc_close: GSK_INVALID_STATE (gsk rc = 5)

This message was seen when new plug-in configuration was reloaded and old configuration was released. It did not have any adverse effect to the Web server and plug-in functionality. Code change was made to ensure right sequence is followed.


PQ86442: Not fail on customer cookies in non-standard format

Plug-in is improved to adopt more flexibility in cookie value parsing. Occasionally, there are
third-party programs that do not follow the standard format to set the Cookie header. When plug-in parses such Cookie header for JSESSIONID, it ignores other cookies by continuing looking until JSESSIONID cookie is found. For example, plug-in now does not fail to get the JSESSIONID cookie from following header:

Cookie: key1;key2=value2;key3=;JSESSIONID=abc (some cookies are not in "name=value" pair)
Cookie: key1=value1,key2=value2;JSESSIONID=abc (Use different separator other than ";")


PQ86467: iPlanet plug-in failed to parse and set headers

iPlanet plug-in did not correctly process multiple escaped characters in request header. When plug-in gets the request headers from the iPlanet Web server, some characters, such as &apos;"&apos; and &apos;\&apos;, are escaped as &apos;\"&apos; and &apos;\\&apos;. Plug-in should send the header without escaping backslash.


PQ88879: Plug-in returned success code while failed to load new plugin-cfg.xml

Plug-in did not set the error code and returned the successful code when it
failed to load the updated plugin-cfg.xml. For IIS plug-in, this could cause
the Web server to hang.


PQ89583: Plug-in marked the appserver down incorrectly

The WebSphere plug-in improperly marks the application server down and
retried the POST request on a different Application Server. For POST
request, after POST data being read from the input stream, it cannot be
retried. Plug-in should fail the request when the request cannot go
through.


PQ92641: Apache plug-in did not send the client SSL certificate

WebSphere Apache plug-in did not send the client SSL certificate to
application server via application server internal header. The correct
Apache Web server environment variable SSL_CLIENT_CERT is now being used to retrieve the client SSL certificate. Plug-in also strips out the footer, header, and newline characters from the certificate so that the certificate is in the format that the application server expects.


PQ93112: Unclosed Connections caused plug-in performance degradation

When plug-in received Windows-style "Connection: Close" header, it did not
process the header correctly, and did not close the connection. This would
introduce a performance degradation.
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Plug-in
Operating system(s): Windows
Software version: 4.0.7
Software edition:
Reference #: 1193143
IBM Group: Software Group
Modified date: Dec 14, 2004