Am Dienstag, 11. November 2003 13:01 schrieb Kalnichevski, Oleg: > > In other words, can we assume that reusing the HTTP connection is > > unreliable/should be avoided if there are more bytes available than > > specified with Content-Length? > > Christian, > Again, there's a similar problem. How long do you think we should wait on a > connection to be really sure that there's no garbage coming out of it? I > think this timeout is the performance hit Odi was talking about. Besides, > regardless how long you wait there can never be 100% certainty that the > connection is completely 'clean'. You could still potentially get some > garbage out of persistent connection when reading the status line of the > following response. So, we are pretty much back to where we started > > You are welcome to come up with a better solution than the exiting, but I > am afraid there's none that it is truly bullet-proof. > > Oleg
I perfectly agree - I do not see a bullet-proof solution either. I should correct my assumption: "Can we assume that reusing the HTTP connection is unreliable/should be avoided if there are more bytes *INSTANTLY* available than specified with Content-Length" "Instantly" means without waiting/blocking, so at least for this situation, a simple workaround would be feasible. I think that the currently used SocketInputStream's available() method _does_ return values > 0. The only additional thing to change is HttpConnection.WrappedInputStream, as it currently lacks an available() method call to the underlying stream. Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
