Hi,
I ran into a problem that doesn't know it should be classified as a
bug. I am using Android 1.6. When I make a post:
POST /OBN/OBNServlet HTTP/1.1
user-agent: Java0
connection: Keep-Alive
content-type: application/x-www-form-urlencoded
accept-encoding: gzip
host: xxx (intentionally removed it)
content-length: 0
I got this response:
HTTP/1.1 200 OK
Date: Mon, 01 Mar 2010 03:48:24 GMT
Content-Encoding: gzip
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain
... (chunked binary data)
If I wrapped the return InputStream by GZIPInputStream and start
reading it:
InputStream is = new GZIPInputStream(conn.getInputStream())
I will encounter a problem reading response from the next post. The
reason is GZIPInputStream will not read the end of chunked encoding
(in hex: 30 0a 0d 0a). After digging into the source code i found the
place that it ignores the last chunked:
InflaterInputStream.java (line 190 to 192)
if (inf.needsInput()) {
fill();
}
Because there is left the end of chunked encoding and the connection
is set to keep-alive, the next post response received (30 0a 0d 0a) as
the header and the rest of the response data as body.
What I have to do to get around the situation is to reference to the
original input stream and read until -1 is reach before closing (note:
if I use GZIPInputStream it will not work because GZIPInputStream all
ready think it doesn't need anymore data).
This is very confusing for developers because GZIPInputStream doesn't
behave as expected as InputStream when you get -1 from read() method.
Can we classified this a bug in GZIPInputStream?
Thanks,
SN
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
