Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C44A26.58D36E81"
Subject: RE: Problems with HttpClient
Date: Fri, 4 Jun 2004 12:23:23 +0100
Message-ID: 
 <825BF35A92B3F0479CC164ECBBE9376EE3B6B8@kccxoex06.corp.kpmgconsulting.com>
Thread-Topic: Problems with HttpClient
Thread-Index: AcRKJLcEcvb+aKHhQk6XpkIAXMjiQQAANi4l
From: "Kalnichevski, Oleg" <oleg.kalnichevski@bearingpoint.com>
To: "Commons HttpClient Project paulo.gaspar"
 <commons-httpclient-dev@jakarta.apache.org>

------_=_NextPart_001_01C44A26.58D36E81
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Paulo,
Apparently you were looking at the HttpClient 3.0 code. The problem has =
indeed been already fixed in CVS HEAD. Make sure you select =
HTTPCLIENT_2_0_BRANCH tag when accessing CVS repository in order to =
retrieve the latest HttpClient 2.0 compatible code

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/?only_with_t=
ag=3DHTTPCLIENT_2_0_BRANCH

Oleg


-----Original Message-----
From:	Paulo Gaspar [mailto:paulo.gaspar]
Sent:	Tue 5/11/2004 17:13
To:	Commons HttpClient Project
Cc:=09
Subject:	Re: Problems with HttpClient
 > ...
 > Do not use HttpMethodBase#getResponseBody or
 > HttpMethodBase#getResponseBodyAsString methods. They are plain =
broken.
 > Both methods are made to ignore I/O errors and return null instead of
 > propagating IOException-s to the caller.
 > ...

When did that happen?

That is not what I see on the sources I have, in which
HttpMethodBase.java has a 2004-03-25 20:37:20 timestamp.

In this version there is no big difference between using any of those
methods.

 From what I see, getResponseBodyAsString() uses the byte array built
by getResponseBody() to build a String from it. Building the String
from the array involves no I/O.

     public String getResponseBodyAsString() throws IOException {
         byte[] rawdata =3D null;
         if (responseAvailable()) {
             rawdata =3D getResponseBody();
         }
         if (rawdata !=3D null) {
            return EncodingUtil.getString(rawdata, =
getResponseCharSet());
         } else {
             return null;
         }
     }

Looking at how the byte array is built, I see that it uses
getResponseBodyAsStream() - which you say is OK - and reads it to that
stored-and-returned byte array without chocking any IOExceptions!

     public byte[] getResponseBody() throws IOException {
         if (this.responseBody =3D=3D null) {
             InputStream instream =3D getResponseBodyAsStream();
             if (instream !=3D null) {
                 LOG.debug("Buffering response body");
                 ByteArrayOutputStream outstream =3D
                             new ByteArrayOutputStream();
                 byte[] buffer =3D new byte[4096];
                 int len;
                 while ((len =3D instream.read(buffer)) > 0) {
                     outstream.write(buffer, 0, len);
                 }
                 outstream.close();
                 setResponseStream(null);
                 this.responseBody =3D outstream.toByteArray();
             }
         }
         return this.responseBody;
     }

Is it bad in CVS now? Was it recently fixed?

I have no CVS access at the moment but, anyway, I think it is important
to make clear if something went wrong and must be fixed or if there is
a misunderstanding of some kind frome one of us about how this methods
are implemented.


Thanks, and have fun,
Paulo Gaspar


Oleg Kalnichevski wrote:
> Anoop,
>=20
> My guess is that some of the methods simply timeout while reading the
> response from the server. Unfortunately, HttpClient does not handle =
this
> situation well. Do not use HttpMethodBase#getResponseBody or
> HttpMethodBase#getResponseBodyAsString methods. They are plain broken.
> Both methods are made to ignore I/O errors and return null instead of
> propagating IOException-s to the caller. Whoever designed those =
methods
> did HttpClient a bad service. Use getResponseBodyAsStream and do the
> reading from the input stream as you see fit
>=20
> Cheers,
>=20
> Oleg
>=20
>=20
> On Fri, 2004-05-07 at 17:01, Anoop Adya wrote:
>=20
>>Hi
>>We have developed a client solution with the help of HttpClient.
>>During the trial run we noticed that it works smoothly for clients and
>>server within the same domain. However, if i try to use HttpClient =
over
>>multiple domains, I get a NullPointerException as getResponseBody =
returns
>>null.
>>Do we need to do something special to handle cross domain requests?
>>Note however that the user is in the same domain as the server we try =
to
>>access.
>>
>>Any pointers would be greatly appreciated.
>>
>>regards, Anoop.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: =
commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: =
commons-httpclient-dev-help@jakarta.apache.org
>>
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: =
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: =
commons-httpclient-dev-help@jakarta.apache.org
>=20
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: =
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: =
commons-httpclient-dev-help@jakarta.apache.org


------_=_NextPart_001_01C44A26.58D36E81
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
------_=_NextPart_001_01C44A26.58D36E81--