Elwin, Martin wrote: > Ortwin, not sure if I understand why a retry only should be done for 1.1. > Would you mind elaborating on the reasons for that? The current retry logic > is valid for both 1.0 and 1.1, as far as I can tell.
Simply because there is no need for a retry in 1.0. Remember 1.0: The server *always* closes the connection. So state of the connection will always be "closed" at the beginning of a request. In 1.1 we have keep-alive connections but which are only kept alive for a certain time. So the connection may be expected open but in fact is closed. Thus a retry is needed after the first attempt. But I am not too happy with your patch. IMHO the problem should be handled by HttpConnetion and not in any higher levels. The problematic call in the code is: connection.isOpen() whose result is unfortunately not related to whether the connection is actually open or closed! So its return value is not well-defined. We'd better fix this HttpConnetion.isOpen() method. Do a read() on the input stream. Unless the connection is open -1 is returned. Unfortunately read() blocks if the connection is open (and no data is available)! Does available() maybe return a meaningful value? This is up to the implementation but should work in theory. (Haven't tried) Martin, could you check this possibility out please? Kind regards Odi -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
