I agree with Oleg here. The real problem is the inability to terminate
a request and force close a connection. Having this functionality would
help in this case as well as many others.
Mike
Oleg Kalnichevski wrote:
I think the shortest example to demonstrate HTTPClient looping endlessly is
Hello,
since this is my first posting to this list, first of all, let me thank all of
you for writing/helping to improve jakarta-commons httpclient.
I would like to present a tiny patch which enables the user to set a maximum
number of bytes to read from a HTTP response.
This patch has proven
Glück [mailto:[EMAIL PROTECTED]
Sent: Friday, October 10, 2003 13:34
To: Commons HttpClient Project
Subject: Re: Proposal: Configurable HTTP Response length limit
Chris,
Thanks for posting. However I really don't see why this should be a
responsibility of HttpClient. The user can always discard
Hi Christian,
I second/third Odi's and Oleg's sentiments. This functionality really
belongs in a layer above HttpClient. If you do create something that
fits into this niche it would be welcomed in the HttpClient contribs
directory.
Mike
On Friday, October 10, 2003, at 06:47 AM,
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
]
Sent: Friday, October 10, 2003 16:12
To: Commons HttpClient Project
Subject: Re: Proposal: Configurable HTTP Response length limit
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
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:
I can easily provide test cases which will cause HttpClient to eat up all
available memory throwing an OutOfMemoryError because of reading and reading
from a never ending HTTP Response.
I would regard this behaviour as a bug.
Sure. The bug in the software on the server side. And the fix
At a lower level, the potential failure points are undoubtedly there.
Unless you could point to a real-world server that causes them, or a
security bug that stems from them, any such fixes would be academic in
nature.
Can you cause an out of memory failure while using
I thought HttpClient was a client for the _real-world_ HTTP-Servers, just as
the HTTP Clients of modern web browsers are/should be (I guess that's why
there is a switch to enable/disable strict mode in HttpClient).
If those so called real world servers do silly stuff, the fix should be
I completely agree with you that we all should write standards-compliant HTTP
web pages/CGI programs/Servlets etc.
Unfortunately, it is not always in our hands. As nearly everybody can write
PHP scripts today, clients which attempt to read from them, should be
error-tolerant.
If you want to
Chris,
Please see my comments in-line
On Fri, 2003-10-10 at 18:29, Christian Kohlschuetter wrote:
I completely agree with you that we all should write standards-compliant HTTP
web pages/CGI programs/Servlets etc.
Unfortunately, it is not always in our hands. As nearly everybody can write
Am Freitag, 10. Oktober 2003 23:40 schrieb Oleg Kalnichevski:
Chris,
Please see my comments in-line
I think it is less the patch itself but a standpoint problem
(standards-compliant vs. robust).
To end this exasperating thread: everybody is invited (but not forced) to use
the provided patch,
Christian,
I would add to my previous two suggestions about using HTTP 1.0 level
support and the Connection:close header, an additional suggestion.
Provide your own connection manager that does not attempt to re-use
connections in a persistent manner, or at least, lets you control
whether to
14 matches
Mail list logo
