Re: Bug in Get.java

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Monday, April 02, 2001 11:16 PM
Subject: Re: Bug in Get.java (was Re: odd code in Get.java)


> Steve Loughran <st...@iseran.com> wrote:
>
> > Should I log this bug on bugzilla?
>
> If you want to. You could wait until your patch has been sent and
> applied and record it as fixed at the same time 8-)

How about I dont submit a fix :-(

The catch and retry trick does not work on my JDK version (1.3.0.01),
something which gets mentioned in some of the user comments at the base of
the bug parade issue -
http://developer.java.sun.com/developer/bugParade/bugs/4160499.html
I also turned off the response code checking for Get.java unless the local
file existed, and costins code doesnt work either, not on my pc.

Other people's workarounds -the fact that you can extract header values then
look for the response code- dont work on my box, instead they throw an
IOException even though getHeaderFieldKey() and getHeaderField() methods
dont raise such exceptions.

Which is bizarre and beyond what I thought the java language spec/runtime
spec said was acceptable. It means that the method :-

    void testSomething (HttpURLConnection connection) {
        String probe=connection.getHeaderFieldKey(0);
    }

will throw an IOException when the connection points to a url of the right
type, even though it compiles happily. Is that really meant to be possible?

So, we have
1. a bug we can replicate, but which hasn't apparently caused an issue in
anyones build since last summer
2. no reliable workaround across java versions short of redoing http
client-side from the ground up
3. a fix promised in the illustrious merlin release (which is practically a
polite way of saying 'later')

Its late, I dont want to bang my head against something that isn't critical
and I dont see can be fixed easily. I'll file it as a but and submit a patch
which reduces the chance of getresponsecode being called in Get.java, so
costin's code will kick in and *maybe* work on other peoples platforms.

For the refactored HttpTask code I'm going to leave the retry code in even
though it doesn't work, because it might work on other JVM instances.

-steve

Re: Bug in Get.java

[Stefan Bodewig <bo...@apache.org>]

Steve Loughran <st...@iseran.com> wrote:

[good arguments snipped]

> Its late, I dont want to bang my head against something that isn't
> critical and I dont see can be fixed easily. I'll file it as a but
> and submit a patch which reduces the chance of getresponsecode being
> called in Get.java, so costin's code will kick in and *maybe* work
> on other peoples platforms.
> 
> For the refactored HttpTask code I'm going to leave the retry code
> in even though it doesn't work, because it might work on other JVM
> instances.

This is fine with me

Stefan