I've been hacking to see why this isn't working. I found that
"Accept-Encoding: gzip, deflate" wasn't being inserted into
the request, so I added it in setConnectionHeaders() (not sure if there's a
better place), since it seems to be ignoring it even if I insert it in the
"Browser-derived headers" page. So now it's working as long as I get it
back as "Content-Encoding: gzip". But, if it comes back as
"Content-Encoding: deflate" (like www.amazon.com does), then it breaks.
After a little investigating, I see that we should be calling
InflaterInputStream() instead of GZIPInputStream() to inflate the stream if
it's encoded with "deflate" (right now we expect "gzip" or nothing). But,
that's not working for me. If I do that, I get an "unknown compression
method" exception from InflaterInputStream(). If I use, ZipInputStream()
instead (as some stuff I've read recommends), then the html parser gets a
parse exception and it loops over and over again adding child after child to
the view results tree. Looks like ZipInputStream is failing in the same
way, but with no exception. Here's the code snippet:
if ("gzip".equals(conn.getContentEncoding()))// works OK even if CE
is null
{
in = new BufferedInputStream( new
GZIPInputStream(conn.getInputStream()));
}
else if ("deflate".equals(conn.getContentEncoding()))
{
in = new BufferedInputStream(new
InflaterInputStream(conn.getInputStream()));
// in = new BufferedInputStream(new
ZipInputStream(conn.getInputStream()));
}
else
{
in= new BufferedInputStream(conn.getInputStream());
}
Anybody ever deal with InflaterInputStream()? I'm not seeing any complaints
about it not working as advertised so I wonder what could be going wrong
here.
J
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
