ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: odd code in
Date Tue, 27 Mar 2001 02:24:34 GMT

----- Original Message -----
From: "Fernando Padilla" <>
To: "ant" <>
Sent: Monday, March 26, 2001 13:15
Subject: Re: odd code in

> I have been away on vacation so I apologize for the late response.
> The reason for the catch and retry is that there is a bug/feature with the
> URLConnection class in java.  What happens is that if there was a bad
> connection, ( like HTTP 404 response.. ), it will throw an IOException on
> first attempt to get the IntputStream.  But on second attempt, you will
> get it ( such as actually getting the HTML response for a 404 error.. ).
> try it and you will see this behavior.  I'm sorry I do not have a url to
> the official description of this (from sun), but I believe it does exist.
> fern

right, I've just scrolled through the 300+ bug parade entries on this

bug ID 4218806
( has
getInputStream throwing a null pointer excepto, and the handler process
being exactly like we have with a different catch and a brief sleep.

equally of interest is bug ID 4333920, which covers how in java1.3.0
getInputStream() will hang until all the data from a chunked connection is
received. We clearly need to include a http1.1 server in the test matrix.
(NB: The current fix is to add to httpd.conf: BrowserMatch "Java1\.3\.0"
downgrade-1.0 )

However the final place I found it was bug ID 4160499
(, which
covers how the HttpUrlConnection class will generate a FileNotFound
Exception when a 4XX error comes in -the second attempt to get the input
stream will succeed.

There is some other related stuff which covers how getResponseCode() (ID
4191815) will also exhibit the same behaviour which will complicate digest
auth somewhat -the check for unauth response was going in elsewhere ahead of
the call to getInputStream.

So, I'm going to
 a) move the catch and code up to where getResponseCode() now is
 b) not catch anything other than FileNotFoundException
 c) after a couple of tries, throw even that exception
 d) make sure there is no call to disconnect() (the null pointer issue)
 e) make sure something in the tests raises the exception. I thought I was
doing so, but will make sure.


View raw message