xxxxx@xxxxx  1999-07-30

Originally, I thought that this bug was another manifestation of 4249722
since the stack traces were similar. Well, 4249722 is fixed and this bug
still happens.

When HttpURLConnection.getResponseCode() is called on the client and
there is an HTTP continue response sent by a Win98 or WinNT server,
the VM will crash:

+ java_cmd=java -classic
+ do_test
+ java -classic -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-M)
Classic VM (build 1.3beta-M, native threads, nojit)
+ java -classic HttpContinueRecvTest -d -v
VERBOSE: Test value[0]=''
VERBOSE: Listening for client request echo on port '10001'.
VERBOSE: Testing HTTP 'default' request.
DEBUG: Connection to 'http://localhost:10000' opened.
DEBUG: Connection to 'http://localhost:10000' completed.
java.lang.StackOverflowError
        at java.io.PushbackInputStream.read(PushbackInputStream.java:162)
        at java.io.FilterInputStream.read(FilterInputStream.java:118)
        at java.io.PushbackInputStream.read(PushbackInputStream.java:168)
        at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:530)
        at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:605)
<deleted 5292 identical lines>
        at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:605)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:475)
        at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:166)
        at HttpRequestDriver.doConnect(HttpRequestDriver.java:135)
        at HttpRequestDriver.makeHttpRequest(HttpRequestDriver.java:290)
        at HttpContinueRecvTest.main(HttpContinueRecvTest.java:94)
Exception in thread "main"

With HotSpot client on a Win98 client, the following happens:

+ java_cmd=java
+ do_test thornback
+ java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-M)
Java Client VM (build 1.3beta-m, mixed mode)
+ java HttpContinueRecvTest -d -v thornback
VERBOSE: Test value[0]=''
VERBOSE: Listening for client request echo on port '10001'.
VERBOSE: Testing HTTP 'default' request.
DEBUG: Connection to 'http://thornback:10000' opened.
DEBUG: Connection to 'http://thornback:10000' completed.
#
# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION
#
# Error ID: 4F533F57494E13120E43505002B0
#

abnormal program termination


With HotSpot client on a S2.6 client, the following happens:

java_cmd=java
+ do_test thornback
+ java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-M)
HotSpot Core VM (build 1.3beta-b-release, 1.3beta-b-release, interpreted mode, release build b)
+ java HttpContinueRecvTest -d -v thornback
VERBOSE: Test value[0]=''
VERBOSE: Listening for client request echo on port '10001'.
VERBOSE: Testing HTTP 'default' request.
DEBUG: Connection to 'http://thornback:10000' opened.
DEBUG: Connection to 'http://thornback:10000' completed.
Segmentation Fault

This bug is reproducible with a Win98 or a WinNT server. It is *not*
reproducible with a S2.6 server.

 xxxxx@xxxxx  1999-09-24

Yingxian determined that this VM crash was caused by extra CR characters
that were accidently included in the HTTP continue response header.

N/A

 xxxxx@xxxxx  1999-09-24

Yingxian tracked this down to a coding error in the HttpEcho server
application. On Win* machine, an extra CR was being generated in the
HTTP continue response. The intent of the test is to exercise the
HTTP continue response and not to exercise the tolerance of extra CR
characters in the HTTP header. I have changed HttpEcho to generate
correctly formatted HTTP responses and the crash has gone away.

We are leaving this bug open because RFC2068 says that extra CR values
should be tolerated by HTTP clients. However, the priority and severity
have both been lowered appropriately.

--

A HTTP Continue followed by invalid response resulted in a 
recursive loop and eventual stack overflow. The issue related
to the re-issue of the MessageHeader in HttpClient.
 xxxxx@xxxxx  2000-08-02

This is a severe problem for several applications. If you don't fix this bug
web robots written in Java cannot use the http classes but have to provide
their own http implementation.

I'm very surprised to see such a lack of concern about a JVM crash.  This shouldn't just be considered a 
problem with HttpEcho, it's a problem with the JVM as well.

As far as HttpEcho goes, the old version found a bug that the new version doesn't.  So it seems like you 
need to add a new test, say HttpEchoExtraCR, to make sure that bug gets fixed and doesn't come back.

In which release of the JVM is this fix going to be 
included?  1.3.1 (if such a release exists) or 1.4?  As the 
other posters above have already said, this is a severe 
problem to those affected.