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 Mon, 14 Apr 2003 15:18:15 GMT
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
> 


Mime
View raw message