Reputation: 3401
Using HttpClient 4.0, Im having an issue where the response I get from the ResponseHandler
is only about half of what the actual page content should be (~61k bytes in the string vs ~125k in the page returned to a browser). I cant seem to find any place where there might be some sort of limit that would limit this. Any ideas?
Update: One other thing I have found is that the size returned by the entity's getContentLength
method is -1, whereas it is a normal value for the previous request. The javadoc seems to indicate that means the length is unknown- Any ideas why that might be the case?
Update2: I tried finding a response for a page more than 80KB. Its interesting that maximum length of the response string is always 18210 characters. Any ideas??
Upvotes: 3
Views: 2463
Reputation: 1020
I found that this was caused by me calling client.getConnectionManager().shutdown()
BEFORE reading the response. I had goofed up one of my finally {}
blocks when doing the request, and the shutdown was causing a race condition which would sometimes kill the response mid-read.
It just so happened that getContentLength()
was returning -1 for me as well, which was caused by the Transfer-Encoding: chunked header. I had assumed that the HttpClient library wasn't dealing with the chunked response correctly, but really it was just my goof up.
Upvotes: 1
Reputation: 718678
The other place you should look is on the server side.
One possibility is that the webapp code is occasionally throwing a wobbly halfway through writing the response. Another is that there's a bug in the server container code. For instance, I vaguely recall that there was a bug in some older versions of Tomcat that caused large responses to be mangled / truncated.
Upvotes: 0
Reputation: 6732
This might not be it, but sometimes this can happen if you aren't flushing a stream somewhere.
Upvotes: 2