Re: DO NOT REPLY [Bug 18439] New: - Unusual Http status line

It seems that it's the HTTP/1.1 request. Wget uses 1.0. If I call HttpMethodBase.setHttp11(false) all works well. Mike On Thursday, March 27, 2003, at 11:30 PM, Jeffrey Dever wrote: Thats strange. When I hit it with wget --debug I get a reasonably formed response: HTTP/1.0 200 Document fol

Re: DO NOT REPLY [Bug 18439] New: - Unusual Http status line

Thats strange. When I hit it with wget --debug I get a reasonably formed response: HTTP/1.0 200 Document follows Date: Fri, 28 Mar 2003 04:25:19 GMT Server: NCSA/1.5.2 Last-modified: Sun, 25 Nov 2001 08:40:58 GMT Content-type: text/html Content-length: 4732 Strange that they used "Document Follo

DO NOT REPLY [Bug 18439] - Unusual Http status line

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 18439] New: - Unusual Http status line

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 10817] - Provide more Example Code

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

Intensive multi-threading example

This might be useful as a demonstration of the issues surrounding connecting to hundreds of sites. In fact, this will generate some nasty outcomes with only a single URL, http://msn.com (it could be said that any connection to this URL is a nasty outcome, but... ^_^). Run this and give it a lis

DO NOT REPLY [Bug 17158] - Realm from authentication challenge unavailable

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 17884] - Multiple DIGEST authentication attempts with same credentials

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 17884] - Multiple DIGEST authentication attempts with same credentials

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 16861] - Digest Authentication fails with Microsoft ISA, appears hung to user

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: NIO

I have been thinking along the same line. Unfortunately, HttpMethodBase and HttpConnection, which is a concrete class, are tightly coupled. They can't be easily decoupled. Another strategy would be to make HttpClient an interface, but unfortunately HttpConnction is being used directly by a few folk

RE: NIO

Dont worry it was just a philosophical question. Do you think it would be possible to extend a new ConnectionManager, HttpConnection and SocketFactory to include NIO as a plugin without breaking backwards compatibility? -Mensaje original- De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]

Re: NIO

HttpClient is being used by a few Apache projects that only recently abandoned 1.1 compatibility (after long and heated debates). I am afraid if we want to play nicely with those folks, JDK 1.4 is no-go for years to come. Oleg On Thu, 2003-03-27 at 18:15, Sergio Berna wrote: > One more question,

RE: doubt about retry

Sergio, This is a very valid point. I believe the entire retry logic should be carefully revised and improved. Clearly, HttpRecoverableException should be more informative by having a status flag or sub-classed into several distinct exception classes. I just feel that should be done in post 2.0

NIO

One more question, but this one is just philosophy and self knowledge. Do you have any plans to work with NIO in some way? I suppose it presents mainly problems with backwards compatibility althought it promises higher control and efficiency over socket streams and several things such as socketcha

RE: doubt about retry

Well, maybe it would be a good suggestion due to the high number of possible causes for a connection failure which go beyond IOException or HttpException to add some sort of status to HttpException so that it could be possible to further get the error cause or at least in which step was the excepti

RE: doubt about retry

Unfortunately, it's not the case Oleg -Original Message- From: Sergio Berna [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 27. März 2003 16:17 To: Commons HttpClient Project Subject: RE: doubt about retry Yes, that was exactly my point. If its sure that a recoverable exception is only thro

RE: doubt about retry

Yes, that was exactly my point. If its sure that a recoverable exception is only thrown if the body has not been sent then its good enough for me to guarantee that no data has gone out of my client. Im not trying to guess if the server has processed something, just that it has not been sent in any

Re: doubt about retry

Sergio, As best I can tell, your stated requirement is one that needs to be handled at the server. Consider: Your client application --> HttpClient --> JRE --> Client OS --> HTTP --> Server OS --> HttpServer --> Server application. and then: Your client application <-- HttpClient <-- JRE <-- C

Re: connections on pool close unexpectedly

Hi Sergio, Thank you for sending your sample code. It has been quite helpful. I have discovered a few interesting things. I have been able to reproduce something similar to what you have been describing. It seems that in JRE 1.2.2 and 1.3.1 (not 1.4.1) that when a connection is closed on th

RE: MultiThread

Thiago MultiThreadedConnectionManager DOES maintain a pool of connections, which, I assume, is what you want. Unlike MultiThreadedConnectionManager SimpleHttpConnectionManager maintains only a single connection at a time. Therefore, chances of getting a timeout on one connection _logically_ s

RE: doubt about retry

Sergio Do not forget that these days people tend to use HTTP protocol for all sorts of things which it has never been envisaged for. HTTP has never been designed to support transactions. HTTP has been designed to support browsing porno-sites (quoting Don Box of Microsoft) There's always a risk

doubt about retry

Hello, I have a small question regarding the HttpException that usually happens when the connection has been closed previous to re-using it. In your schema you advise to retry the connection, since a new request is likely to work. The problem im facing is wheter i can be absolutely sure that the

RE: MultiThread

Hi Oleg, First, thanks for your response. I´m actualy using with MultiThreadedConnectionManager, but when i change to MultiThreadedConnectionManager the connections timeout has decreased a lot. With MultiThreadedConnectionManager appears greater than SimpleHttpConnectionManager. It´s correct or

RE: Mutual SSL Authentication Using HTTP Client

Hi Max, We do not have such an example available. This is as close as it gets: http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/ EasyX509TrustManager.java & EasySSLProtocolSocketFactory.java classes extend standard SSL classes in ord

Mutual SSL Authentication Using HTTP Client

Does anyone have a simple example of configuring the HTTP Client to connect to a secure server that demands client authentication. i.e. an example where the client has to retrieve the appropriate digital certificate and private key from its keystore and then initialise the HTTP Client accordingly.

RE: MultiThread

Hi Thiago I regret that your message has been ignored for so long. 1. connection timeouts are perfectly legitimate from the HTTP spec standpoint. HTTP servers are not supposed to keep connection alive for too long. Probably HttpClient should be a bit smarter when encountering a stale connecti

RE: HttpClient and CPU usage.....

Thank you all for your assistance. I downloaded the nightly drop yesterday and will go about compiling it today and testing under JDK 1.4. -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 1:09 PM To: Commons HttpClient Project Subject: R

RE: [FEEDBACK NEEDED]: Authentication logic completely refactored

Hi Mike, > is there a need for someone to supply their own AuthScheme? it seems that all of the choices are now hard coded. I am perfectly aware of limitations of the current design in this regard. Clearly, adding custom authentication schemes or extending/customizing existing ones should be