Re: ERROR in http://jakarta.apache.org/commons/httpclient/tutorial.html

Oleg Kalnichevski wrote: I apologize for inconveniences and extra work caused by my mistake. Oleg Nop. I did not had any inconveniences ;-) Erare humanum est - Seneca. King regards -- Thorsten Scherler Tfno: 955 062 627 Email: [EMAIL PROTECTED] -

DO NOT REPLY [Bug 27109] - HTTP Client doesn't support multipart/related content-type

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: two post requests

Hi Roland, and thank you for the detailed answer. It helped. It's the "hard case" I have to deal with, but this is ok. I missed some understanding about how these forms work, now everything is clear. Thank you again, Diana Hello Diana, there are some possible cases... you'll have to analyse the p

Cookie rejected problem

Hi all, I'm using httpclient 2.0 and i'm encountering this problem when i try to connect to https://www.socialsecurity.be/login/login_fr?j_target_url=%2Fsrd%2Findex .jsp using a get method : 24-fevr.-2004 11:58:35 org.apache.commons.httpclient.HttpMethodBase processResponseHeaders ATTENTION: Cook

Re: Cookie rejected problem

Hello Xavier, your first action should be to contact the administrator of that web site and tell him that the cookie configuration is all screwed up. No browser should accept a cookie for .smals-mvm.be coming from socialsecurity.be, let alone HttpClient. It would be a security violation to do so.

Re: streaming request body

For (a), Oleg's response is correct. You might easily be confused, in the sense that HttpClient's API inverts the control. It is not that you write to an "OutputStream" to send your data, it is that you provide HttpClient with an "InputStream", and it reads that stream and sends the data. H

Re: streaming request body

John Keyes schrieb: For (a), Oleg's response is correct. You might easily be confused, in the sense that HttpClient's API inverts the control. It is not that you write to an "OutputStream" to send your data, it is that you provide HttpClient with an "InputStream", and it reads that stream a

Re: streaming request body

John Keyes wrote: In both cases, it is possible to get the behavior that you desire. Not it is not. Again think of XXX,000 of requests. I am getting a little angry by now. C'mon man, we wrote this baby and we know very well what's possible with it. So please don't tell us it can not do unbu

Re: streaming request body

Stefan Dingfelder wrote: I am missing something here from both views. Maybe I am wrong but as I understand it, I can provide any InputStream. And that must not be a file on disk (which I dislike also - except for large files or live streams that cannot be put to memory in total) but can be any o

RE: streaming request body

John Just for the record: HttpClient 2.0 design is completely broken in many, many wonderful ways, and we are perfectly aware of that. Excuse my lack of understanding, however, I do think that applies to the current implementation of the content streaming. Allow me to reiterate that HttpClient

Re: streaming request body

John Keyes wrote: For (a), Oleg's response is correct. You might easily be confused, in the sense that HttpClient's API inverts the control. It is not that you write to an "OutputStream" to send your data, it is that you provide HttpClient with an "InputStream", and it reads that stream and se

Re: streaming request body

On 24 Feb 2004, at 14:36, Stefan Dingfelder wrote: John Keyes schrieb: For (a), Oleg's response is correct. You might easily be confused, in the sense that HttpClient's API inverts the control. It is not that you write to an "OutputStream" to send your data, it is that you provide HttpClien

Re: streaming request body

On 24 Feb 2004, at 14:39, Ortwin Glück wrote: John Keyes wrote: In both cases, it is possible to get the behavior that you desire. Not it is not. Again think of XXX,000 of requests. I am getting a little angry by now. C'mon man, we wrote this baby and we know very well what's possible with it.

Re: streaming request body

Again, comments and feedback or a patch for bug 26070 would be welcome. Okay, I'll investigate it more and see what I come up with, -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PR

Re: streaming request body

Ortwin Glück schrieb: Stefan Dingfelder wrote: I am missing something here from both views. Maybe I am wrong but as I understand it, I can provide any InputStream. And that must not be a file on disk (which I dislike also - except for large files or live streams that cannot be put to memory in

RE: streaming request body

> But a *segment* will be held in memory prior to writing to the output > stream though. For XXX,000 requests I think this is an unreasonable > memory overhead. John, Just to make sure I understand you correctly, you are saying that your application will be processing XXX,000 requests *concurre

Re: streaming request body

John Keyes schrieb: On 24 Feb 2004, at 14:39, Ortwin Glück wrote: John Keyes wrote: In both cases, it is possible to get the behavior that you desire. Not it is not. Again think of XXX,000 of requests. I am getting a little angry by now. C'mon man, we wrote this baby and we know very well w

Re: streaming request body

On 24 Feb 2004, at 16:22, Kalnichevski, Oleg wrote: But a *segment* will be held in memory prior to writing to the output stream though. For XXX,000 requests I think this is an unreasonable memory overhead. John, Just to make sure I understand you correctly, you are saying that your applicatio

RE: streaming request body

> come along) and work from there - we need to process around 70,000 > requests a minute. But not concurrently, right? So, the memory overhead is (No of concurrent connections) * (buffer size). Even if you had 1,000 concurrent SOAP requests, with 2K buffer you would still end up with 2,048 * 1

DO NOT REPLY [Bug 27194] New: - Redirects to the above link work but the host information in the method is not updated

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 27194] - Host configuration properties not updated when the method is redirected

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: Cookie rejected problem

You're absolutely right, Roland, i was about sure about it but with your confirmation, there is no doubt. Thank you for your reply -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: mardi 24 fevrier 2004 13:05 To: Commons HttpClient Project Subject: Re: Cookie rejected