hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Still problems with HttpRecoverableException and HTTPS
Date Tue, 15 Apr 2003 01:13:55 GMT
I've been able to reproduce this problem reliably.  It seems to be 
specific to certain web servers.  Below is what I've been running with 
a variety of URLs:

         HttpClient client = new HttpClient();

         GetMethod get = new GetMethod(url);

         System.out.println("Get 1: " + get.getStatusCode());

         synchronized (Thread.currentThread()) {
             try {
             } catch (InterruptedException e) { }

         get = new GetMethod(url);
         System.out.println("Get 2: " + get.getStatusCode());

Different servers have different timeouts, so the wait number needs to 
be varied a bit.  Some servers seem to cause an exception when writing 
the second request, where others do not until the read.  In particular 
I've noticed the following:

	Apache 2.0.40, Apache Coyote 1.0 (Tomcat) and IIS 6.0 all cause errors 
on the write and are therefore retried.

	IBM HTTP Server 1.3.26 (Apache 1.3.26) and SunONE 6.0 (NCSA) both 
cause errors on the read and therefore are not retried.

I played around with flushing the output stream and 
inputStream.available().  Neither seem to do the trick.  I also tried 
adding a HEAD test method when reusing a connection and, though not 
optimal, it worked.  I will post code for this in case anyone is 

And so the saga continues...


On Monday, April 14, 2003, at 11:59 AM, Carl A. Dunham wrote:

> This is really bugging me, because I know this is a well-known problem 
> in
> Java. Unfortunately, Google doesn't seem to have much to offer, other 
> than
> people asking the same question in different contexts.
> I did, however, find this:
> http://vic20.blipp.com/pipermail/icq-devel/2002-November/005446.html
> with the suggestion to use InputStream.available() to test if the 
> connection
> is still valid. If someone has a reliable test case, maybe this is 
> something
> to try.
> SO_KEEPALIVE may also be helpful here.
> On Monday April 14 2003 11:18, Michael Becke wrote:
>> Yes, our choices for connection testing, that involve hitting the
>> server, are HEAD, OPTIONS and TRACE I believe.  I think OPTIONS and
>> TRACE are best from a functionality perspective, but they only exist 
>> in
>> HTTP 1.1.  I do not know if HEAD has any side effects and what it 
>> would
>> do for a URL meant for POSTs (a METHOD_NOT_ALLOWED status perhaps). I
>> think the big question here is when would we want to do this?
>> Another random thought.  Would doing a out.flush() at the end of a
>> request cause an exception when the socket is closed?
>> Mike
>> Mike Moran wrote:
>>> Ortwin Gl├╝ck wrote:
>>>> Michael Becke wrote:
>>>>> The obvious best solution would be to figure out a way to determine
>>>>> if a connection has been closed by the server.
>>>> The only way to do this, is to perform read / write on the 
>>>> connection,
>>>> which is sad.
>>> Wouldn't it be possible to send an OPTIONS[1] request just before you
>>> send the real request? As this doesn't really do anything it should 
>>> be
>>> harmless semantically, and should cause an exception if the socket is
>>> buggered. Obviously it's an extra overhead on each request but 
>>> perhaps
>>> it could be optionally or heuristically enabled?
>>> [1]: http://rfc.net/rfc2616.html#p52
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional
>> commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org

View raw message