RE: [REMINDER] HttpClient IRC event - irc log

Here is the complete session: Session Start: Thu Feb 27 12:01:16 2003 Session Ident: #httpclient * Now talking in #httpclient * Topic is 'Jakarta Commons HttpClient discussion 20:00-22:00 UTC Thursday Feb 27' * Set by Jandalf on Wed Feb 26 13:30:33 (Offtopic) Oh, if any of you use windows, Torto

Re: [REMINDER] HttpClient IRC event - irc log

The IRC session we had today went well. Except that we only captured about 1/4 the discussion in a logfile (darn buffers). The big topics of the day were what to do about redirects and when to create development branches. The general concensus was that 2.0 beta development should focus on correc

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy wait

--- Additional Comments From [EMAIL PROTECTED] 2003-02-27 22:27 --- > The patch applied is a good solution to the problem. No extra threads are > created and the polling loop is slowed down greatly by blocking the current > thread in 50ms intervals. Maybe I'm missing something, but since

Bug: News page has wrong date

Hi all, I just noticed a minor gotcha while showing someone at work the News page at http://jakarta.apache.org/commons/httpclient/news.html. The first item has the wrong date: "25 January 2003" rather than "25 February 2003". -- Laura -

DO NOT REPLY [Bug 17166] - HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

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: RFE: Method to return an InputStream that includes both HTTP headers and HTTP body

To achieve this, wouldn't HttpClient have to reconstruct the headers in a fact input stream just like Jesus was originally doing? I mean, we *have* to read the headers to handle redirects so we can't just return the original stream. It seems like this may as well be done outside of HttpClient, bu

Re: RFE: Method to return an InputStream that includes both HTTPheaders and HTTP body

Definitely ... unless of course setFollowRedirect() is set to false. Ortwin Gl|ck wrote: Jesus M. Salvo Jr. wrote: At the moment, the HttpMethod interface has a method getResponseBodyAsStream() that returns an InputStream of the HTTP body. I need a method that returns the _entire_ HTTP response

Re: DO NOT REPLY [Bug 17166] - HttpClient does not compile 'outof the box' in IBM's VisualAge IDE

Mike, Patch looks fine. I wouldn't worry about this too much however, as its really up to the bug poster to provide patches to super-ultra-unusual-antiquated-unaviailable-development-environments. [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS T

DO NOT REPLY [Bug 17487] - waitForResponse is using busy wait

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 17487] - waitForResponse is using busy wait

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: [PATCH] Wire logging revised (attempt 3)

I think its justified too. The copywrite date in any new files should just be 2003. Odi's name might have been munged again. Other than that, its cool. Might need come updates to the xdocs/logging.xml logging guide? Oleg Kalnichevski wrote: Jandalf I have tried to incorporate your suggest

DO NOT REPLY [Bug 10807] - Handle virtual hosts, relative urls, multi-homing

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: MultipartPostMethod creating malformed headers?

>What library are you using to parse 'multipart/form-data' > formatted requests? We actually have our own classes to parse a multipart/form-data formatted request. I guess they could be a bit outdated at this point, or possible never were completely spec compliant themselves. The specification h

Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relativeurls, multi-homing

That would also suffice. If possible, I would prefer to pass an implementation of the interface in to HttpConnection upon creation rather than have it as a global setting, but I presume that's easier anyway. I'm not exactly sure how it would get implemented but it could be on a per connection b

DO NOT REPLY [Bug 17487] - waitForResponse is using busy wait

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:[REMINDER] HttpClient IRC event - date set

Somewhere deep in middle earth a gathering of the great elks begins Just a reminder and time zone clarifier that the inagural HttpClient IRC event is scheduled to start around about now. Everyone's invited to join us at irc.freenode.net channel #httpclient. Adrian Sutton, Software Engineer

Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relativeurls, multi-homing

Michael Becke wrote: I would support addition regardless, but then that's just me. I assume by "custom DNS resolution" you mean passing in the resolved values eg the HttpClient library is told: "here's the Name/IP mapping, do a GET to this IP with this Host: "? I was thinking more along the l

DO NOT REPLY [Bug 17432] - '100-continue' response times out unexpectedly

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: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Laura CPU-bound polling is needed only under fairly unusual circumstances. I do think that any sort of thread based solution would be an overkill. I did my best to explain the rationale for not using threads in the bug report Cheers Oleg On Thu, 2003-02-27 at 20:23, Laura Werner wrote: > Ol

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Oops. Other Mike:) Mike Moran wrote: Oleg Kalnichevski wrote: Mike May I add your comments to the bug report? Ye, sure. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so You can do threads fairly efficiently by pooling them. I do it in my cache, since I have to allow a timeout on the whole transaction and abort the transaction even in the middle of read

DO NOT REPLY [Bug 17487] - waitForResponse is using busy wait

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: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Oleg Kalnichevski wrote: Mike May I add your comments to the bug report? Ye, sure. -- Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Please do. Mike Oleg Kalnichevski wrote: Mike May I add your comments to the bug report? Oleg On Thu, 2003-02-27 at 19:01, Mike Moran wrote: Michael Becke wrote: Agreed. A second thread should not be needed though. It can be done using something like: [ ... ] Oleg Kalnichevski wrote: [ .

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Mike May I add your comments to the bug report? Oleg On Thu, 2003-02-27 at 19:01, Mike Moran wrote: > Michael Becke wrote: > > > Agreed. A second thread should not be needed though. It can be done > > using something like: > > [ ... ] > > > > > > > Oleg Kalnichevski wrote: > > [ ... ] > >

Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relativeurls, multi-homing

I would support addition regardless, but then that's just me. I assume by "custom DNS resolution" you mean passing in the resolved values eg the HttpClient library is told: "here's the Name/IP mapping, do a GET to this IP with this Host: "? I was thinking more along the lines of an interface tha

Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relativeurls, multi-homing

[EMAIL PROTECTED] wrote: [ ... ] --- Additional Comments From [EMAIL PROTECTED] 2003-02-27 18:37 --- I'd like to go ahead and tackle this one, but I need a little clarification. Does the following correctly describe what we want? - we want to perform a get on www.google.com, let's say

DO NOT REPLY [Bug 10807] - Handle virtual hosts, relative urls, multi-homing

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 17166] - HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

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 17166] - HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

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: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Michael Becke wrote: Agreed. A second thread should not be needed though. It can be done using something like: [ ... ] Oleg Kalnichevski wrote: [ ... ] Oleg On Thu, 2003-02-27 at 15:36, Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per

DO NOT REPLY [Bug 17487] - waitForResponse is using busy wait

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: HTTPClient query

Hello Dheeraj, The subscription should go through almost immediately. If you are subscribed you will get this email twice. Also, Dheeraj it would help if you could give a more detailed example of what you are doing and what it not working. In particular a test case that fails for you and tha

Re: Question about HttpConnection and Having problems with HTTPSproxy tunneling

I think this relates directly to the posting today by Jani Mattsson. As best I understand it, when using HTTPS to connect via a proxy server, the connection to the proxy server itself is not encrypted (the CONNECT method goes to the proxy server unencrypted). Only once the connection has been

Re: [PATCH] 'expect: 100-continue' handshake revisited

Folks Any comments, objections, suggestions to this one? Oleg On Wed, 2003-02-26 at 22:25, Oleg Kalnichevski wrote: > I have been trying to resolve the bug related to 'expect - continue' > handshake. We have been making some progress but I still have no clear > idea what may be causing this prob

DO NOT REPLY [Bug 17487] - waitForResponse is using busy wait

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: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Agreed. A second thread should not be needed though. It can be done using something like: long overtime = System.currentTimeMillis() + timeout_ms; while (System.currentTimeMillis() < overtime) { if (isResponseAvailable()) { return true; } e

[PATCH] Wire logging revised (attempt 3)

Jandalf I have tried to incorporate your suggestions into the new patch. I left ugly cast unchanged, though. I believe it's justified in this specific case Any other comments, suggestions, objections? Cheers Oleg On Thu, 2003-02-27 at 14:37, Oleg Kalnichevski wrote: > On Thu, 2003-02-27 at 06:

Re: Question about HttpConnection

Mike, I think this relates directly to the posting today by Jani Mattsson. As best I understand it, when using HTTPS to connect via a proxy server, the connection to the proxy server itself is not encrypted (the CONNECT method goes to the proxy server unencrypted). Only once the connection h

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

I am not sure. We do not need down to ms precision there. We might put the thread to sleep for 10 to 25 ms prior to polling for data again. I would see it as lesser of two evils Oleg On Thu, 2003-02-27 at 15:36, Ortwin Glück wrote: > Oleg Kalnichevski wrote: > > Odi, are you sure you want to h

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so Oleg Better than a busy wait, isn't it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EM

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so Oleg On Thu, 2003-02-27 at 15:27, Ortwin Glück wrote: > [EMAIL PROTECTED] wrote: > > waitForResponse should not block infinitely. It should be able to timeout after > > given number of ms if no response is forthco

Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait

[EMAIL PROTECTED] wrote: waitForResponse should not block infinitely. It should be able to timeout after given number of ms if no response is forthcoming. If you see a more elegant Java 1.2.2 compatible solution, please advise us Oleg There is Object.wait(long) and Object.notify and Thread.sleep(lo

Re: call for projects using httpclient

Done. Looks like a cool project! http://jakarta.apache.org/commons/httpclient/applications.html Max Voelkel wrote: Hi middle earth, yet another project using Jakarta Commons HttpClient. It's the result of my (yet unfinished) diploma thesis. I apologize for my bad english. When i made a mistake,

DO NOT REPLY [Bug 17487] - waitForResponse is using busy wait

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: Having problems with HTTPS proxy tunneling

Revisiting my own posting, the problem seems to be that in HttpClient.executeMethod(HostConfiguration hostConfiguration, HttpMethod method), in case the connection is not already open, in case of a proxied secure connection, the method is wrapped into a ConnectMethod: method =

DO NOT REPLY [Bug 17487] New: - waitForResponse is using busy wait

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: Significant HttpClient & HttpMethodBase overhaul. Need early feedback

Cause with current CVS if an exception occurs reading response, the exception is going back to main thread, and even worse the connection isn't released (cause responseStream is null, so releaseConnection() does nothing), leaving connectionManager in a wrong state :( This should be fixed now. rel

DO NOT REPLY [Bug 17166] - HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

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 17166] - HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

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: [PATCH] Wire logging revised (attempt 2)

- certainly would prefer Wire, WireLogInputStream, WireLogOutputStream to be package access, not public So do I. I just find it illogical that HttpMethodBase and all classes derived from it reside in different packages. That causes the problem in the first place. Visibility of Wire, WireLog

Re[2]: call for projects using httpclient

Hi middle earth, yet another project using Jakarta Commons HttpClient. It's the result of my (yet unfinished) diploma thesis. I apologize for my bad english. When i made a mistake, feel free to correct it. I just wanted to say thanx by beeing part of the growing applications-page. What about th

Re: [PATCH] Wire logging revised (attempt 2)

On Thu, 2003-02-27 at 06:24, Jeffrey Dever wrote: > Hey Odi, > A few comments: > > - certainly would prefer Wire, WireLogInputStream, WireLogOutputStream > to be package access, not public So do I. I just find it illogical that HttpMethodBase and all classes derived from it reside in different p

DO NOT REPLY [Bug 16419] - Test case failure for testConnTimeout

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: DO NOT REPLY [Bug 16419] - Test case failure fortestConnTimeout

Looks good +1 Oleg On Thu, 2003-02-27 at 05:48, [EMAIL PROTECTED] wrote: > 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 CO

Having problems with HTTPS proxy tunneling

Hi! I am using commons-httpclient in a setup where I'm making connections to a secure HTTPS server over a proxy server. I use POST-requests, and the first request always works fine (albeit a bit slow because of SSL handshaking or something). Subsequent request work fine if I do them soon enough a

Re: Significant HttpClient & HttpMethodBase overhaul. Need earlyfeedback

Sam Maloney wrote: Makes sense to me, I would definatly agree on your point that 'Client' logic should be in HttpClient and not in HttpMethodBase. (I would say redirect, auth and even auto-retry would count as 'Client' logic). [ ... ] I would also agree. I would like and expect my use of the l

RE: call for projects using httpclient

Hi Jandalf, Sorry for the delay but i've tons of work Newknow is a Knowledge Management Suite based on Artificial Intelligence, Collaboration and Document Management and we use Commons-httpClient as part of our Knowledge Spider which retrieves all the information gathered by

RE: Significant HttpClient & HttpMethodBase overhaul. Need early feedback

Sam Maloney a écrit : > > Makes sense to me, > I would definatly agree on your point that 'Client' logic should be in > HttpClient and not in HttpMethodBase. (I would say redirect, auth and > even auto-retry would count as 'Client' logic). > > Sam As for the auto-retry stuff, I agree it makes the

DO NOT REPLY [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.

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: MultipartPostMethod creating malformed headers?

Daniel, The MultipartPost have been recently revised to be more spec compliant. It appears it has become a bit 'too compliant' for your CGI script to handle. What library are you using to parse 'multipart/form-data' formatted requests? Each part now includes 'Content-Type' and 'Content-Transfer-Enc

Re: [PATCH] 'expect: 100-continue' handshake revisited

Ingo, The patch was not supposed to solve the bug, as I still have no clear idea what may be causing the problem in the first place. It is merely a refactoring and code improvement patch, that should make 'expect-continue' stuff more robust. It appears the problem is somehow related to the use of

Re: Using httpclient on the server to intercept and modify HTTP response

Hi Adrian, Thank you for your detailed answer. I'd just like to check that I've understood okay, and ask one more favour (!): 1./ I can't determine what type of credentials I should use directly with the HttpClient API. I need to look at HTTP response headers and determine that myself. This l

Re: [PATCH] 'expect: 100-continue' handshake revisited

Hi Oleg, I have tried your patch. Unfortunately it does not solve the problem. Sorry, that I cannot give you more help, but I also have no idea what might be causing that problem. Regards, Ingo > I have been trying to resolve the bug related to 'expect - continue' > handshake. We have been makin

Re: RFE: Method to return an InputStream that includes both HTTPheaders and HTTP body

Jesus M. Salvo Jr. wrote: At the moment, the HttpMethod interface has a method getResponseBodyAsStream() that returns an InputStream of the HTTP body. I need a method that returns the _entire_ HTTP response, including the HTTP headers and body, in a single InputStream. I assume in case of redir

Re: MultipartPostMethod creating malformed headers?

Can you post the response headers? You could use wire log to see them. Daniel Walsh wrote: I'm getting a new exception thrown by the servlet I'm pointing to when I use today's (Feb. 26th) source for MultipartPostMethod. It complains about a malformed header line. When I point back to an older ve

Re: HttpClient IRC event - date set

Damn, I will be at the climbing wall at that time Jeffrey Dever wrote: The inagural HttpClient IRC even will be held tomorrow: Date: 20:00-22:00 UTC Thursday Feb 27 Server: irc.freenode.net Channel: #httpclient Tenative Agenda: - Middle Earth nicks - Redirect architecture - Branch strategy an