After we upgraded our web application in our customer’s place, lots of users started complaining that the webpage is not getting downloaded to their browser…

Observation

• This issue happens only in Windows 98 and some machines with WindowsXP without any service packs. And that too only when accessing the server with HTTP 1.1 compression ENABLED. We confirmed this by requesting the customer to turn off HTTP 1.1 compression and he confirmed that the application worked fine.
• Fortunately, we were able to reproduce this issue locally in one of our Test Machines running Win98. We found that this issue happens only when we go thru Web Server. When we accessed the application via Application Server, the issue was NOT reproduced.
• The above observation led us to another important clue, that this issue could be something to do with SSL, as that is one major difference between Web Server and App Server.

Based on all the above observation, we concluded that this issue happens only with HTTP 1.1 enabled Browser accessing the Bali Server via SSL. And the machine is running Win98 or plain Winxp(without any service packs) operating Systems.

With the above information at hand, we started monitoring the HTTP Traffic between Browser and Server using some Network Sniffing tools and found that a particular javascript file called “FMProduct.js” seems to be the culprit. Even though the file was downloaded to the Browser, the file never got written to the Temporary Internet Files cache.

Concluding that this file is the one that could be causing all the problems we tried to take the file separately and tried to access it via Weblogic Web Server and we were successfully able to reproduce the problamatic behavior.

To eliminate the possibility of Weblogic Server in playing a role in the above erratic behavior, we hosted the FMProduct.js on Apache Web Server. And now, we were able to download the file without any problems from any browser.

Now, we concluded that apart from the combinations of SSL, HTTP1.1, Win98/xp, there is yet another variant, Weblogic Server playing a role in the erratic behavior.

We monitored the network traffic when accessing Apache Web Server as against Weblogic Web Server. We found something very interesting. That is, Weblogic serves the files in a CHUNKED manner with chunk size of 4072 bytes(we are not sure what is the significance of this number). Apache serves the whole content of the file in one chunk.

The problem occurs ONLY when the last chunk is of size between 1 to 9 bytes. In other words, if the size of the file is 4074 or 4081 or 8119 etc…
The size of compressed version of FMProduct.js is 20362 – which means 5 chunks of 4072 and the last chunk contains 2 bytes.

Resolution

It certainly seems that Microsoft has fixed this erratic behavior with SSL + HTTP 1.1 combination, and hence the latest version of Windows XP (SP2) does not have this erratic behavior.

Additionally, we shall also review our build process to see if we can add a check to see if the file size falls into this magic number and if so, try and add some more insignificant characters to increase the file size.

Please note that the above erratic behavior is NOT reproduced in Mozilla FireFox? browser.

The attached Ruby Script helps print out all the files that fall into this wierd pattern.

require “find”
if ARGV[0].nil?
puts “Usage: ruby FileChunkSizeFinder.rb [path_of_baliweb]”
exit
end

Find.find(ARGV[0]) do |file|
if File.file?(file) && File.basename(file) =~ /\.gz$/ && (1..9) === File.size(file)%4072
puts file + ” ==> ” + File.size(file).to_s
end
end

In quite a few occassions, we would have to sniff SSL Traffic between the browser and a iPlanet Web Server. To sniff SSL using ClearWatch Tool, we require the Private Key file in PEM format.

IPlanet stores keys internally. Hence we need to go thru a few steps to achieve the above…

Step 1 :
Firstly, the Key will have to be exported to a PKCS#12 file.

To export to a PKCS#12 file, Use the pk12util command that ships with iplanet. This file is generally available under Servers\bin\https\admin\bin folder

Syntax :
pk12util -o exportfile -n certname [-d certdir] [-P dbprefix]

Example :
pk12util -o c:\temp\pkey.txt -n Server-Cert -d c:\iplanet\servers\alias -P dbprefix

In the above dbprefix is nothing but the prefix for the Key file available under Servers\alias folder. If the key file is xyz-key3.db, then dbprefix is ‘xyz’

Step 2 :
Once you have a pkcs12 file containing a private key, you can convert it to a PEM file by using the freely available OpenSSL tool,

Syntax :
openssl pkcs12 -in server.p12 -out server.pem -nocerts -passin pass:yourpassword -passout pass:dummy

where “server.p12” is the original PKCS#12 file you are converting and “yourpassword” is the password that is associated with the PKCS#12 file.

Step 3 :
Now, we can remove the Password Protection on the Key by running the following command.

openssl rsa -in server.pem -out server.key -passin pass:dummy