hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Johnson <sjohn...@mercury.com>
Subject RE: HTTPClient 2.0 - Limiting response body read length
Date Thu, 09 Dec 2004 18:07:03 GMT
Hi All,

Thanks to everyone who replied. The information was
helpful in getting this working.

The info below and on calling method.abort() were

Steve Johnson, Software Engineer, sjohnson@mercury.com
direct 720.564.6532 


-----Original Message-----
From: Eric Johnson [mailto:eric@tibco.com] 
Sent: Thursday, December 09, 2004 10:55 AM
To: HttpClient Project
Cc: 'Oleg Kalnichevski'; David Clements; Steve Johnson
Subject: Re: HTTPClient 2.0 - Limiting response body read length

This happens because HttpClient thinks that it should be treating the 
connection persistently.  That means it has to consume the rest of the 
response so that the same socket can be reused for the next 
request/response pair.

You can prevent this by adding the "connection: close" header on the 
request.  HttpClient will then close the socket immediately upon closing 
of the response stream, regardless of how much of the response stream 
remains to be consumed.


Steve Johnson wrote:

>Hi Oleg and All,
>Thank you for this excellent information.
>The next problem is that when the inputStream is prematurely closed the auto-watcher continues
consuming the
>stream looking for EOF, which we don't want.
>We want to stop reading so that we do not spend time or memory on
>more info than we want.
>// see HttpMethodBase.releaseConnection(), close(), notifyWatcher(), close, close,
>Thanks for your help,
>Steve Johnson, Software Engineer, sjohnson@mercury.com
>direct 720.564.6532 
>-----Original Message-----
>From: Oleg Kalnichevski [mailto:olegk@apache.org] 
>Sent: Monday, December 06, 2004 11:33 AM
>To: HttpClient Project
>Cc: David Clements; Steve Johnson
>Subject: Re: HTTPClient 2.0 - Limiting response body read length
>Do not override the method. Better provide a simple helper class to
>consume the response body as a stream. See this discussion for
>additional pointers:
>We are trying to deemphasize the use of HttpMethod#getResponseBody and
>HttpMethod#getResponseBodyAsString and deprecate these methods
>altogether in 4.0

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message