On Tuesday 11 November 2003 15:35, Eric Johnson wrote: > > In the end, I've got a few concerns: > * I'm not sure I see the point of trying to catch the problem at the end > of the previous response, which would seem to be the point of the > "available" check, rather than at the beginning of reading the next > response. > * Are there particular servers that demonstrate bad behavior that we > want to catch with this new option? Do we have test cases for those > particular servers? > * Has it been tested across a myriad of environments? > > Such changes for the 2.1 CVS HEAD are fine by me. I'm much more > concerned about the 2.0 branch, however, and keeping what changes we do > there to a minimum. This change seems to straddle the boundary between > a bug-fix and additional functionality, at least from where I sit. Then > again, I've not looked closely at the patch, I've only followed the > discussion. > > -Eric.
Eric, I agree that the patch is not required for the 2.0 branch (I am working with HEAD, anyway). I have submitted an additional, hopefully self-explaining test case for the surplus-data problem. Just have a look at it and tell me what you think. Regarding the available() function, I have found a "diplomatic" solution: Instead of calling conn.getResponseInputStream().available() directly, I will use conn.isResponseAvailable(). That call returns immediately per definition. Having eventually problems with available() in the future, we would simply have to change that method accordingly. Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
