Re: Proposal: Configurable HTTP Response length limit

[Eric Johnson]

I would think that if your application has any reason to believe that 
the response will be unbounded, then you should use getResponseBodyAsStream.

I suppose would could add functions that took a limit parameter for the 
functions getResponseBody() and getResponseBodyAsString().  Something like:

byte[] getResponseBody(int maxBytes);

and deprecate the old one.  In the absence of such support in 
HttpClient, presumably you can write such a function for yourself?

I agree with other posts that this is not an issue to solve at the 
stream level.

-Eric.

[EMAIL PROTECTED] wrote:

Am Freitag, 10. Oktober 2003 13:33 schrieb Ortwin Glück:
 

Chris,

Thanks for posting. However I really don't see why this should be a
responsibility of HttpClient. The user can always discard the rest of a
response if he wants to. I my eyes you are solving the problem at too
low a level. The only problem that arises is with endless streams, since
HttpClient always tries to consume the input stream until the end. The
only thing you need is a way to forcibly end a connection.
Odi
   

Odi,

thanks for your answer.

Indeed, endless streams (or streams returning more bytes than the JVM's free 
memory size) are the big problem of the current HttpClient.

HttpMethodBase's getResponseBody() has no hard limit and will cause the 
application to crash with an OutOfMemoryError when you are reading from a 
stream which is too long.

Then, you should probably mark getResponseBody and getResponseBodyAsString as 
deprecated because they will not terminate normally in this case.

Christian

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]