DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Proposal: Configurable HTTP Response length limit

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 ru

DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: [VOTE][RESULT] 2.0 RC2 release

The revision of the ChunkedInputStream#close() method only reinforced my belief that the problem should not be solved by a work-around suggested by Christian. A better solution, in my opinion, would be to provide a means of interrupting HTTP methods. Oleg On Fri, 2003-10-10 at 18:52, Kalnichevski

Re: Proposal: Configurable HTTP Response length limit

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 t

Re: Proposal: Configurable HTTP Response length limit

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

Re: Proposal: Configurable HTTP Response length limit

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

Re: Proposal: Configurable HTTP Response length limit

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 ru

Re: Proposal: Configurable HTTP Response length limit

If you are determined to work with a server that sends limitless responses (an odd use of HTTP - I'd recommend an alternative protocol such as BEEP, with its chunks that you could consume forever. Keep in mind, for example, that there could be a proxy server in the middle that thinks it should

RE: [VOTE][RESULT] 2.0 RC2 release

Mike and all We have two issues pending: possible connection leak in HEAD methods with redirect & ChunkedInputStream#close(). Let us hold off the release until these issues are thoroughly looked into. Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Friday, O

RE: Proposal: Configurable HTTP Response length limit

> 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 a

DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Proposal: Configurable HTTP Response length limit

Am Freitag, 10. Oktober 2003 18:02 schrieb Kalnichevski, Oleg: > > 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

Re: Proposal: Configurable HTTP Response length limit

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 getResponseBodyAsStream(

RE: Proposal: Configurable HTTP Response length limit

> 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 f

Re: Proposal: Configurable HTTP Response length limit

Am Freitag, 10. Oktober 2003 17:01 schrieb 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 g

Re: Proposal: Configurable HTTP Response length limit

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:

RE: Proposal: Configurable HTTP Response length limit

Chritian, Allow me to express my opinion that overriding HttpMethodBase#getResponseBody & HttpMethodBase#getResponseBodyAsString and providing a response length check inside those two methods seems (at least to me) a better approach than poking around with low lever input stream objects. An impl

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. 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.

DO NOT REPLY [Bug 23708] - DefaultHttpParamsFactory violates applet sandbox

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23708] - DefaultHttpParamsFactory violates applet sandbox

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Proposal: Configurable HTTP Response length limit

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, Christia

DO NOT REPLY [Bug 23708] - DefaultHttpParamsFactory violates applet sandbox

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Proposal: Configurable HTTP Response length limit

Chris, I have to agree with Odi. The proposed functionality is not generic enough, can be (more or less) easily implemented on top of the standard HttpClient and therefore does not really warrant in my opinion an inclusion into the main code tree. Oleg -Original Message- From: Ortwin G

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 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 Http

DO NOT REPLY [Bug 23708] - DefaultHttpParamsFactory violates applet sandbox

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Proposal: Configurable HTTP Response length limit

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

Re: [PATCH] MultiThreadedHttpConnectionManager and CLOSE_WAIT

Andrea Fabris wrote: line 681: + socket.setSoLinger(true, 0); 0 might not be supported by the Linux kernel. Try (true, 1) or (false, 0). Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROT

[PATCH] MultiThreadedHttpConnectionManager and CLOSE_WAIT

I tried to fix the problem on the last source i got from the repository (9-10-2003), but from my test setting the SO_LINGER timeout doesn't achieve any result. I send the patch i made because i don't know if i applyied it right or not (i mean i don't know if i set the SO_LINGER in the right place)

Re: MultiThreadedHttpConnectionManager question

Kalnichevski, Oleg wrote: Odi, If there's enough confidence that setting linger time to 0 will not have an unexpected adverse effect, the fix can be included into 2.0. I do not know TCP/IP that well to make that call, though. Oleg From RFC-739 3.5: When a connection is closed actively, it

RE: MultiThreadedHttpConnectionManager question

Odi, If there's enough confidence that setting linger time to 0 will not have an unexpected adverse effect, the fix can be included into 2.0. I do not know TCP/IP that well to make that call, though. Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Friday, Oct

Re: MultiThreadedHttpConnectionManager question

Kalnichevski, Oleg wrote: I think we should add this feature in CVS HEAD only. Oleg Not a 100 % sure. If the sockets remain in that state forever this could be a major resource leak which should be fixed. Setting the linger time to 0 should be okay for us. -

DO NOT REPLY [Bug 23708] - DefaultHttpParamsFactory violates applet sandbox

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: MultiThreadedHttpConnectionManager question

I think we should add this feature in CVS HEAD only. Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 04:37 To: Commons HttpClient Project Subject: Re: MultiThreadedHttpConnectionManager question This definitely looks like the problem

DO NOT REPLY [Bug 23703] - Freezes w/ MultiThreadedHttpConnectionManager

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu