Fixed
Status Update
No update yet.
Comments
en...@google.com
do you have a small test case that demonstrates the problem?
ew...@gmail.com
An attached android application demonstrates the problem. It must be executed on
device/emulator with internet access. The archive contains Eclipse android project.
The code can be executed on RI with minimal changes.
device/emulator with internet access. The archive contains Eclipse android project.
The code can be executed on RI with minimal changes.
en...@google.com
thanks. i see what you mean now: if we close a chunked input stream without reading
to the end, if that stream is recycled, the next user gets the tail of the first
user's unread data.
while minimizing the test case, it looks like your only workarounds are:
1. always read to the end, even if you don't want the data (so there's no junk left
to read).
2. if you really don't want to read to the end, don't close (so the unclosed
connection won't get recycled).
i have a fix out for review.
to the end, if that stream is recycled, the next user gets the tail of the first
user's unread data.
while minimizing the test case, it looks like your only workarounds are:
1. always read to the end, even if you don't want the data (so there's no junk left
to read).
2. if you really don't want to read to the end, don't close (so the unclosed
connection won't get recycled).
i have a fix out for review.
Description
Your development environment: Windows XP, eclipse-SDK-3.5M7
Describe the problem:
The chunked HTTP input stream doesn't hurry the underlying stream. It is a critical problem for
the persistent connections. So, if the current chunk is read and the input stream contains more
data (chunks or optional trailers), the connection will be cached will a dirty stream. The next
usage of that connection will return the data from the previous one.
org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection.ChunkedInputStream is
guilty of this.