java version "1.3.0rc3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc3-Z)
Java HotSpot(TM) Client VM (build 1.3.0rc3-Z, mixed mode)

My applet needs to communicate to the web server. The communication
is implemented via URLConnection relative to the document base.
The responce to the request has extended lifecycle (something analogous
to HTTP media streaming, i.e. the data arrives in chunks in the body
of response).

The problem is, getInputStream in 1.3 doesn't seem to return until
the response is finished (socket dropped on the server side.)

All Java VMs prior to 1.3 and old browsers (except NS6 which uses 1.3)
seem to work fine.

Live example available at http://demo.c.uroam.com/delaytest/index.htm
the applet source at http://demo.c.uroam.com/delaytest/MainApplet.java
the Apache module generating data at
http://demo.c.uroam.com/delaytest/test_module.cpp

The example url first spits out around 3K of text to exclude buffering as
the explanation for the problem, then generates a line every 4 sec 10 times.
(Review ID: 103808) 
======================================================================
additional information:

Just as a new input: this bug shows up only when the Content-Length
header in the reply is not set. 
But, as this is not a "must have" header, it's still a bug.

Thanks a lot!
Igor

 xxxxx@xxxxx  2000-04-27

With Apache the workaround is to put the following in
httpd.conf :-

BrowserMatch "Java1\.3\.0" downgrade-1.0

 xxxxx@xxxxx  2001-01-04

Seems odd. Can't find anything in the relevant code.
I have to reproduce it.

jean- xxxxx@xxxxx  2000-09-14


In 1.3 we upgraded to a HTTP/1.1 client and web servers (esp. Apache)
return a chunked encoded response to a http 1.1 client. When we get
a chunked encoded response we wait for the last chunk to arrive so
that we can merge the footer fields into the header. So essentially
this bug is that we need to improve our chunked encoding handling 
so that the response from the server can be streamed to the 
application. The issue with this is that the content length isn't
known in advance so we need to be careful not to break applications
that depend on getContentLength. 

See also 4314224 which is the RFE to support chunked encoded
requests.

 xxxxx@xxxxx  2000-11-24

In merlin we have replaced our chunked encoding implementation.
The new implementation means that the input stream can be returned
to the application immediately. In addition we aren't limited by
chunk boundaries so it's possible for application to read into
the current chunk even if the chunk hasn't been completely read
yet.

For developers suffering with this issue with 1.3.x they can
workaround the issue by preventing the server returning a chunked
response. In Apache this can be done by inserting the following
into httpd.conf :-

BrowserMatch "Java1\.3\.[0-1]" downgrade-1.0

 xxxxx@xxxxx  2001-01-11

I get the same problem with 1.3.0-C. The call to 
URLConnection.getInputStream() hangs until the request 
finishes. Works fine with 1.2.2_005.

I am unable to do HTTP streaming or progressive loading with 
1.3.0

I've reduced the problem to a reasonably small test case,
which I'd be glad to forward on request.  What I find really
peculiar is that getInputStream blocks if I let Apache
generate the HTTP headers itself, but if I run my CGI as "no
protocol headers" and generate the same header information
in the CGI, getInputStream doesn't block!

Version information:

$ java -version
java version "1.3.0beta_refresh"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.3.0beta_refresh-b09)
Java HotSpot(TM) Client VM (build 1.3.0beta-b07, mixed mode)

... just wanted to confirm that I have encountered the same
problem ... I'm doing a database query by invoking a CGI
script using a URLConnection and would like to be able to
interrrupt it ... but because getInputStream() does not
return until
the response is complete, I have no place to check for an
interrupt exception
... thanks in advance for any suggestions ...

Don

Please Sun. This is a very bad bug, since we need this to 
go thru firewalls with Java.
This will make the task of using URLConnection with keep-
alive impossible !!!

Sun, this is so disappointing...

It's a BUG, not a request for enhancements, and it takes
you more than half a year to fix.

All java versions prior to 1.3 had functionality
that enabled a WHOLE CLASS of streaming applications.
Now it's BROKEN. What am I supposed to tell my customers
when Netscape 6 goes out? Don't use it?

I've encountered the same problem, too. Please fix this bug!

This WORKED in 1.2.2, and is BROKEN in 1.3. This REGRESSION
is a BUG. It means (at a minimum) a major redesign of our
product to produce something that won't work nearly as well.
If this is true after all the development we've put into it,
I can guarantee we will NEVER USE JAVA for another product.

Over two months ago I offered assistance in reproducing this
BUG. The offer still stands. If "xxxxx@xxxxx" would kindly
contact me, I'd be glad to supply my test case and any other
information that might help.

Sorry for shouting... but can you sense my frustration?

Yes, we got the same problem with our application. The 
applet can't get an input stream to a server side CGI 
script until the script finishes all the response. And the 
same application is working for 1.2.2.

C# is coming - and sooner than you can say "Sun fixed that 
Java bug" (while remaining truthful).

Sun should keep a separate bug list for newly introduced inconsistencies such as this. Regardless of how 
many people vote for this one, a bug that breaks existing client/server apps with no workaround is way 
more serious than some fillRect () thread safety issue.

The odd thing is my HTTP streaming applet does work in 
Netscape 6.0 but not when using the same plug-in in IE, 
Netscape 4.7x or Opera. What's the story?

Robust HTTP/HTTPS handling is a key component of Java 
(another being high-quality platform independent UI 
components).  It is thus essential that bugs in this area 
be fixed ASAP!

I'm in the process of scrapping my URLconnections and using 
Socket instead. Works fine. But it's a stupid bug 
nonetheless. This should not have happened and should be 
fixed by now.

I am getting the same problem which is major in my case and 
I will be forced to write some kind of cheesy work around.  
This bug should be fixed ASAP!

I'm from the FileNotFoundException <- getInputStream() community
What helped me was using HTTPClient in place of the java.net.HttpURLConnection class.  Get it at,
http://www.innovation.ch/java/HTTPClient/
For my *much* longer post see "Applets+Plug-in+Proxy=HTTP connect fails" in the Java Plug-in forum at the 
JDC

Sun must be kidding to not release a service release that 
fixes the bug in a matter of days! Bugs like this make Java 
an awful platform for serious HTTP development.

A possibly simpler workaround would be to make the
clients protocol version configurable. For example
the HttpURLConnection class might have a method
setProtocolVersion(String ver) with ver="1.1" by default.

I am having the same problem, and also if the network is 
down the readline call of the BufferedReader to the 
URLConnections input stream never returns, neither it 
throws any exception, the client applet just seems like 
hanged !

-Deeps

I have the same problem connecting back to tomcat 3.2.2 
from an applet. Here is a dodgy workaround. 

1.In your applet start a new thread that creates an 
URLConnection and calls getInputStream(). This thread will 
block forever according to the bug report.
2. In your original thread, create another URLConnection 
and call getInputStream(). This function call now returns 
as expected.
3. You can stop() the blocked Thread if you want.

I have no idea why this works.

Another workaround not dependent on Apache is that the
client adds a header "TE: identity". This should force
the server not to use chunked encoding while still
enabling other features of HTTP/1.1. This works with
TomCat, but for example not with iPlanet 4. IMO it should
work with any HTTP/1.1 compliant server.

I'm seeing this to as I stream progress back to the client 
from a lengthy query.  I've tried:  BrowserMatch "Java1\.3\.
[0-1]" downgrade-1.0 on the IBM HTTP Server (Apache), but I 
can't get it to work.  My next thought is a sniffer, but 
this doesnt help with IIS 4.0.   Thanks,  Brian

Would anybody care to explain slightly more in detailed 
that browsermatch tag.  I can't get it to work only for 
Java 1.3 with "Java1\.3\.[0-1]" but it does work when using 
the variable "Java".

I think i am running into the same problem, except 
sometimes mine never returns.  I just stays at 
getInputStream.  I dont have any control over the http 
server that is giving me the html page.  What can i do?

I notice a similar thing but instead with an SSL session.  
With the Java1.3.0, the getInputStream doesn't block and 
allows client applets to read streamed data. But with 
Java1.3.1, the problem exists..the applet halts until the 
socket is closed...and at that point the plugin JVM 
releases the buffered data to the client.  

I don't think Apache is at fault here as the status line in 
Netscape clearly shows that it's reading more and more 
bytes (due to the streaming data).  So the Java1.3.1 Plugin 
JVM is just not releasing it to the client code.

Sun, what has changed in the SSL implementations with these 
plugin versions?

Also, on a minor note, the User-Agent is set 
to "Mozilla..." within an SSL session but is "Java1.3.0..." 
in a non-SSL session..making it harder when using the 
BrowserMatch directive.

I'm running the said plugins on Win2K on Netscape 
Communicator 4.78 with Apache 1.3.2/Tomcat 3.2.3 on HP-UX 
11.x

Stalin D'Souza
sdsouza@siac.com

Indeed when writing a more powerfull server under Solaris the bug is much more severe than it is described as here especially when dealing with huge amounts of data in multiple threads. 
1. The JVM is consuming 100% of the CPU while waiting for response on getInputStream. Forget about performance of the whole system. Indeed there are such incredible effects out of bad performance that the system behaviour becomes quite unpredictable
2. The whole amount of data is buffered and this is a problem with 50 threads reveiving 50Mb each. It is not clear what the maximum amount of memory allow to the JVM should be a gig or two, more... despite the efforts to make realy neat stream processing with as little overhead as possible
BUT indeed there is a soilution to the problem (not all people are as sloppy and dump as Sun) check out the HTTPClient it offers Streaming of both send and receive indeed with very little patching of code I were able to troubleshoot the incredibly bad problems created by the core Sun technology

Can't we have a patch for 1.3 to include this fix?? It's 
extremely important for any type of streaming content 
handling on the client.  

Just want to mention that I'm using the HTTPClient package 
from innovation.ch and it seems to work very well.  At 
least it doesn't stop my development while I wait for JDK 
1.4.  A bonus, it includes the full source so if there's a 
problem I can fix it myself... 

For Apache/JServ I have fixed this problem by explicitly
setting the Content-Length variable using
HttpServletResponse.setHeader() method. However this did not
work once we upgraded from JServ to Tomcat.

BrowserMatch never worked for me.

I'll probably try to implement my own URLConnection class
and go from there. Thanks, SUN!

You indicate that this defect is closed and fixed.  How and 
where did you fix it?  I'm using JDK 1.4 and it's still a problem.

I need this to work with both IIS and Apache. With 1.4.0 all 
works great (thanks). With 1.3.1 it works with Apache if I 
include the BrowserMatch thing but it doesn't work with IIS. 
Please fix 1.3.1 so that it works with IIS too.

1.4 works fine (thanks) 

Hi folks! For all people in trouble with this bug according 
apache-tomcat communication, try to use ajpv13 instead of 
ajpv12! This may help. Regards!

I'm using 1.4.2 applet to connect to Servlet running on Tomcat.  Calling con.getInputStream() blocks. I've tried two suggestions con.setRequestProperty("TE", "identity") and I've tried to use a separate thread.  Both results failed.  Does anyone know a work-around or if this is fixed in 1.5?

Ignore my last comment.  I was forgetting to close the connection on the client side.  Doing con.disconnect() seemed to prevent the problem from occurring.

I'm using 1.4.2 applet to connect to Servlet running on 
Tomcat.  Calling con.getInputStream() blocks. I've tried 
two suggestions con.setRequestProperty
("TE", "identity") and I've tried to use a separate thread.  Both results failed.  Does anyone know a work-around or if this is fixed in 1.5?

Same problem here.  This page says closed,fixed, so where is the fix?  In what version of the JDK does it work?

Also, I just wanted to add that calling disconnect on the connection unblocked the getInputStream under Windows XP with the following JDK :
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

Unfortunately, it did not work under linux with JDK 1.4.2_02.

Http/1.1 has persistent connections, if it is true: why all the client-server java applications closes the connection when sends the response of a request????   What  can I do to use persistent connections???