[
https://issues.apache.org/jira/browse/HTTPCLIENT-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219179#comment-13219179
]
Oleg Kalnichevski commented on HTTPCLIENT-1170:
-----------------------------------------------
And what does this tell you? HttpClient uses Content-Length value specified in
the response head to delineate message body. Apparently the server is sending
fewer bytes that declared by the Content-Length causing HttpClient to block in
a read operation while expecting more data. Your own code behaves exactly the
same way.
There can be several possibilities for such behavior. (1) The content-length
value is miscalculated on the server side. Common browsers seem to have special
logic that enables them to detect and recover from such situations. (2) The
server fails to send enough content for some reason.
You can see what physically gets sent across the wire by using a packet sniffer
such Wireshark. If you are still convinced the problem is on the client side
please create a _self-contained_ web application I could deploy locally _and_ a
client side test case that can be used to reproduce the problem against a local
servlet engine, then re-open the issue and attach both artifacts to it.
Oleg
> Incomplete data received from servlet
> -------------------------------------
>
> Key: HTTPCLIENT-1170
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1170
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.3
> Environment: java 1.7.0_0, Windows 7 x 64, Apache 7.0.22, connections
> are made throug http://localhost
> Reporter: Aniceto Pérez y Madrid
> Priority: Blocker
>
> Hi
> I have this servlet that generates on the fly a binary response by
> serializing an object. buf size is about 30 KB. I've been using this code to
> serve files for a long time. If I access that servlet using any web browser,
> the received file is OK.
> byte[] buf = respObject.stringBinSerialize();
> response.setContentLength(buf.length);
> response.setContentType("binary/octet-stream");
> response.setStatus(HttpServletResponse.SC_OK);
> OutputStream out = response.getOutputStream();
> out.write(buf);
> out.flush();
> Now I have this client code and it doesn't receive the full response.
> byte[] completo = new byte[0], temporal;
> byte[] cbuf = new byte[4096];
> int cuenta = 0, esta = 0;
> HttpParams params = new SyncBasicHttpParams();
> HttpConnectionParams.setSocketBufferSize(params, 64000);
> HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
> HttpClient httpclient = new DefaultHttpClient(params);
> try {
> HttpPost httpost = new HttpPost(targetURLinclServletName);
> HttpGet httpget = new
> HttpGet("http://localhost:8080/myservlet";);
> HttpResponse response = httpclient.execute(httpget);
> HttpEntity entity = response.getEntity();
> if (entity != null) {
> System.out.println("ent sz " +
> entity.getContentLength() + " chk " + entity.isChunked() + " is rept " +
> entity.isRepeatable() + " str " + entity.isStreaming());
> // completo = EntityUtils.toByteArray(entity);
> System.out.println("bytearrayed " + completo.length);
> InputStream instream = entity.getContent();
> while (completo.length != entity.getContentLength()
> && (esta = instream.read(cbuf)) != -1) {
> if (selector.equals(RPCdefs.SELECTOR_PROYLIST) ||
> true) {
> cuenta += esta;
> System.out.println("readline" + esta + " van
> " + cuenta);
> System.out.println("sz " +
> entity.getContentLength());
> }
> temporal = new byte[completo.length + esta];
> System.arraycopy(completo, 0, temporal, 0,
> completo.length);
> System.arraycopy(cbuf, 0, temporal,
> completo.length, esta);
> completo = temporal;
> temporal = null;
> }
> }
> EntityUtils.consume(entity);
> } finally {
> httpclient.getConnectionManager().shutdown();
> }
> The simplest way to receive is EntityUtils.toByteArray(entity), but it gets
> hung. The loop for partial copy is to know how may bytes are received. They
> are about 17845. The initial params were added to check if the issue was
> related to flow control, but with 64 KB buffers it doesn't changes anything.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
