Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Wed, 29 Feb 2012 13:19:57 +0000 (UTC)
From: "Oleg Kalnichevski (Commented) (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: 
 <877072112.2806.1330521597995.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1754398024.2051.1330509837673.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HTTPCLIENT-1170) Incomplete data received from
 servlet
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1170?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D13219179#comment-13219179 ]=20

Oleg Kalnichevski commented on HTTPCLIENT-1170:
-----------------------------------------------

And what does this tell you?  HttpClient uses Content-Length value specifie=
d 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 behav=
es exactly the same way.=20

There can be several possibilities for such behavior. (1) The content-lengt=
h value is miscalculated on the server side. Common browsers seem to have s=
pecial 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 sni=
ffer such Wireshark. If you are still convinced the problem is on the clien=
t side please create a _self-contained_ web application I could deploy loca=
lly _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 art=
ifacts to it.

Oleg
               =20
> Incomplete data received from servlet
> -------------------------------------
>
>                 Key: HTTPCLIENT-1170
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-117=
0
>             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, connect=
ions are made throug http://localhost
>            Reporter: Aniceto P=C3=A9rez y Madrid
>            Priority: Blocker
>
> Hi
> I have this servlet that generates on the fly a binary response by serial=
izing an object. buf size is about 30 KB. I've been using this code to serv=
e files for a long time. If I access that servlet using any web browser, th=
e received file is OK.
> =09=09=09byte[] buf =3D respObject.stringBinSerialize();
> =09=09=09response.setContentLength(buf.length);
> =09=09=09response.setContentType("binary/octet-stream");
> =09=09=09response.setStatus(HttpServletResponse.SC_OK);
> =09=09=09OutputStream out =3D response.getOutputStream();
> =09=09=09out.write(buf);
> =09=09=09out.flush();
> Now I have this client code and it doesn't receive the full response.=20
>                 byte[] completo =3D new byte[0], temporal;
>                 byte[] cbuf =3D new byte[4096];
>                 int cuenta =3D 0, esta =3D 0;
>                 HttpParams params =3D new SyncBasicHttpParams();
>                 HttpConnectionParams.setSocketBufferSize(params, 64000);
>                 HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_=
1);
>                 HttpClient httpclient =3D new DefaultHttpClient(params);
>                 try {
>                     HttpPost httpost =3D new HttpPost(targetURLinclServle=
tName);
>                     HttpGet httpget =3D new HttpGet("http://localhost:808=
0/myservlet");
>                     HttpResponse response =3D httpclient.execute(httpget)=
;
>                     HttpEntity entity =3D response.getEntity();
>                     if (entity !=3D null) {
>                         System.out.println("ent sz " + entity.getContentL=
ength() + " chk " + entity.isChunked() + " is rept " + entity.isRepeatable(=
) + "  str " + entity.isStreaming());
> //                        completo =3D EntityUtils.toByteArray(entity);
>                         System.out.println("bytearrayed " + completo.leng=
th);
>                         InputStream instream =3D entity.getContent();
>                         while (completo.length !=3D entity.getContentLeng=
th() && (esta =3D instream.read(cbuf)) !=3D -1) {
>                             if (selector.equals(RPCdefs.SELECTOR_PROYLIST=
) || true) {
>                                 cuenta +=3D esta;
>                                 System.out.println("readline" + esta + " =
 van " + cuenta);
>                                 System.out.println("sz " + entity.getCont=
entLength());
>                             }
>                             temporal =3D new byte[completo.length + esta]=
;
>                             System.arraycopy(completo, 0, temporal, 0, co=
mpleto.length);
>                             System.arraycopy(cbuf, 0, temporal, completo.=
length, esta);
>                             completo =3D temporal;
>                             temporal =3D null;
>                         }
>                     }
>                     EntityUtils.consume(entity);
>                 } finally {
>                     httpclient.getConnectionManager().shutdown();
>                 }
> The simplest way to receive is  EntityUtils.toByteArray(entity), but it g=
ets 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 w=
as related to flow control, but with 64 KB buffers it doesn't changes anyth=
ing.=20

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org