Name: vi73552			Date: 03/23/99


This is a resubmit of bug 4186995.

The java plugin 1.2 has a problem handling 404 error messages from 
certian web servers.   The problem occurs when loading a jar file.
See the description below from the bug page for 4186995

              Fri Feb 19 06:57:08 PST 1999
                                 yankeejason
                                 Well, another update, since sun isn't moving on this one. Please note I only get the crash
                                 in IE4. NS browser works ok. 

                                 If I hit a demo applet on sun's site (see my comments above for url), it works fine. If I
                                 copy the same applet and html page to my web server and browse it from there, it
                                 crashes IE. Same if recompile the applet or just use the .class file straight off the demo
                                 page.

                                 So, I started tracking down the bug. Watching the java console, I saw that the crash
                                 happened right after the applet tried to load the <appletclass>BeanInfo classes, which
                                 don't exist (the vm will generate on the fly). Betting that the only difference between the
                                 plugin getting a "not found" from sun's server and a "not found" from my server would be
                                 the http header, I wrote a http message tracer in java.

                                 What I found was that when the applet would request the beaninfo class from Sun's
                                 server (running Apache 1.3.3), the server sent a simple 404 Not Found with a few
                                 standard header lines: content-type, content-length, Server, and a no-cache pragma. When
                                 I pulled the same applet from my dev web server (running MS IIS4.0) the 404 included an
                                 extra header entry, content-length.

                                 After reviewing the latest http1.1 draft, I see no reason why a server should not include a
                                 content length entry with a 404, to indicate the length of the html body being sent with the
                                 user friendly explanation of the not found.

                                 So, I modified my trace program to strip content-length headers out of 404 responses,
                                 which cured the problem. For production, I wrote an IIS ISAPI filter which strips
                                 content-length entries from 404 response headers.

                                 I should point out that this problem can (and most likely does) affect other servers beside
                                 IIS; any server returning content-length in a 404 should cause the problem. I'm planning to
                                 open a new bug report with sun on this with further documentation; the correct long term
                                 solution is for the IE version of the plugin to not barf when seeing a 404 with
                                 content-length while retreiving a .class file. Meanwhile, I am looking into setting up a
                                 small personal web site to publish my http trace program and the Isapi filter.


In our experience it is not the content-length causing the problem
but something else in the text of the 404 error coming back. We
are running the domino server and have no filter control over 
the messages returned to the user.  


To recreate the bug.  Follow the instructions above.  By downloading 
and serving  one
 of Sun's demo apps on a domino or IISS server will enable you to 
recreate the problem every time.
(Review ID: 55964) 
======================================================================