###@###.### 2004-07-12

J2SE Version (please include all output from java -version flag):
  java version "1.5.0-beta3"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta3-b57)
  Java HotSpot(TM) Client VM (build 1.5.0-beta3-b57, mixed mode)

Does this problem occur on J2SE 1.3, 1.4 or 1.4.1? Yes / No (pick one)
  No, it works fine with build 51; Tiger beta2

Operating System Configuration Information (be specific):
  WinNT

Bug Description:
  Sun plugin 1.5.0 Beta3 build 57 does a get on JARJAR and PACK.GZ applet
  files, when Sun plugin 1.5.0 Beta2 build 46 did not. This nullifies any
  benefits of the reduced size of the PACK.GZ applet files.
 
 
Details:
   Our applets run in most browser environments, and thus we support CABs
   for the MSJVM, JARJAR files for the Sun 1.4.x plugin and .PACK.GZ files
   for the Sun 1.5

   plugin. To facilitate this, we have a servlet that examines the requested
   file extension and also the Accept-Encoding HTTP header, and then sends down
   the appropriate version of the applet to the client. The applet tag in the
   client is not JVM-aware i.e. it does not change based on the JVM being used
   and is a static entry in the HTML file. Our applet tag looks similar to the
   following:

<applet width="1" height="1" code="EntrustTruePassApplet.class"
 name="EntrustTruePassApplet"
    archive="https://server.entrust.com/TruePassSampleApp/servlets/AppletDownloadServlet/entrusttruepassapplet-epf.jarjar"

codebase="https://server.entrust.com/TruePassSampleApp/servlets/AppletDownloadServlet/" mayscript>
 
    <param name="namespace" value="TruePass EPF 8,0,0,0">
    <param name="useslibrary" value="TruePass EPF 8,0,0,0">
    <param name="useslibrarycodebase"
value="https://server.entrust.com/TruePassSampleApp/servlets/AppletDownloadServlet/entrusttruepassapplet-epf.cab">
    <param name="useslibraryversion" value="8,0,0,0">
 
    <!-- Other params here -->
 
</applet>

   Thus, the Sun plugin always sees the .jarjar file extension for our applets.
 
   With 1.5.0 Beta2 build 46 everything worked fine - the plugin requests the
   jarjar file with the accept-encoding header set to pack200-gzip and our
   servlet returns the pack.gz file with the content-encoding set to
   pack200-gzip. This download request happened just once, and future requests
   got fulfilled by the plugin's cache.
 
   With 1.5.0 Beta3 build 57, there seems to be a problem - the plugin requests
   the jarjar file first with the accept-encoding header set to pack200-gzip,
   and then a second time but this time without the accept-encoding header.
   This causes both the pack.gz and .jarjar versions of our applet to get
   downloaded to the client JVM. It seems that the first request that has the
   accept-encoding header set to pack200-gzip is not caching the applet.
 
   Also attached are two text files with the dump from the plugin's console.
   Search for the word "encoding" in the dumps: it can be seen that Beta3 build
   57 tries the download twice: one with "basic: encoding = pack200-gzip" and
   then with "basic: encoding = null".
 

Submitter confirmed its not a bug.



###@###.### 2004-07-26