RE: Problems with HttpClient

["Kalnichevski, Oleg" <ol...@bearingpoint.com>]

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_tag=HTTPCLIENT_2_0_BRANCH

Oleg


-----Original Message-----
From:	Paulo Gaspar [mailto:paulo.gaspar]
Sent:	Tue 5/11/2004 17:13
To:	Commons HttpClient Project
Cc:	
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 = null;
         if (responseAvailable()) {
             rawdata = getResponseBody();
         }
         if (rawdata != 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 == null) {
             InputStream instream = getResponseBodyAsStream();
             if (instream != null) {
                 LOG.debug("Buffering response body");
                 ByteArrayOutputStream outstream =
                             new ByteArrayOutputStream();
                 byte[] buffer = new byte[4096];
                 int len;
                 while ((len = instream.read(buffer)) > 0) {
                     outstream.write(buffer, 0, len);
                 }
                 outstream.close();
                 setResponseStream(null);
                 this.responseBody = 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,
> 
> 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
> 
> Cheers,
> 
> Oleg
> 
> 
> On Fri, 2004-05-07 at 17:01, Anoop Adya wrote:
> 
>>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
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 
> 


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