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 possible. However, such plugability mechanism, in my opinion, should have wider scope than just authentication schemes. HttpClient should provide capability to 'plug-in' custom cookie policies, cookie implementations, redirect validators, and what not, without having to recompile standard HttpClient package. Besides, such plugability mechanism would also call for a better configuration architecture. I just felt such a radical change had to be postponed at least until 2.0 release should the various auth/* classes be public? Well, it depends how we envisage the usage of those classes. If we assume that custom authentication schemes would be placed in 'httpclient.auth' package, package visibility would clearly suffice. That would, however, rule out possibility of putting custom authentication schemes into a different package, such as 'com.mycompany.onehellofauthscheme'. Would not that be a bit too constraining? HttpState should use standard bean naming conventions for preemptiveAuthentication, something like isAuthenticationPreemptive() and setAuthenticationPreemptive() Agreed there are some small style problems, and unused imports I'll try to clean up a bit. If no other objects are raised by 21:00GMT today, I'll commit the patch. I think we should move on and work out minor quirks as they are discovered Many thanks for your feedback, Mike Cheers Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 27. März 2003 04:19 To: Commons HttpClient Project Subject: Re: [FEEDBACK NEEDED]: Authentication logic completely refactored Hi Oleg, I like the new design. It makes things much simpler and more modular. I have only a few minor questions/comments: - should the various auth/* classes be public? - is there a need for someone to supply their own AuthScheme? it seems that all of the choices are now hard coded. - HttpState should use standard bean naming conventions for preemptiveAuthentication, something like isAuthenticationPreemptive() and setAuthenticationPreemptive() - there are some small style problems, and unused imports Again, very nice work. Mike On Wednesday, March 19, 2003, at 03:09 PM, Oleg Kalnichevski wrote: Folks, I know I have been a pain in the rear ;-) Your feedback would be highly appreciated. I know it is quite a bit of a patch ;-) So, you are welcome to start throwing bad tomatoes at me [Taking cover] Oleg On Wed, 2003-03-19 at 20:59, [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884 Multiple DIGEST authentication attempts with same credentials --- Additional Comments From [EMAIL PROTECTED] 2003-03-19 19:59 --- While working on a fix for this bug I have come to realize that any sort of clean solution would require an almost complete authentication logic redesign. Authenticator#authenticate method needed to be more modular, so that HttpClient class could access information about authentication scheme being used. Besides, authentication parsing logic was a complete mess. I was not sure I could fix it without introducing subtle bugs IMPORTANT: The patch retains full API compatibility with the existing version. No existing code should be broken. This patch should also fix the following bugs: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17158 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16861 You'll have to perform some manual adjustments after having applied the patch: - create org.apache.commons.httpclient.auth package - move AuthChallengeParser, AuthenticationException, MalformedChallengeException, AuthScheme, AuthSchemeBase, BasicScheme, DigestScheme, NTLMScheme, RFC2617Scheme, HttpAuthenticator classes to the newly created package Oleg PS: New classes have not been documented yet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: Re: HttpClient and CPU usage. Busy wait has been fixed after 2.0a3 release. So, a recent nightly build is needed. Besides, it turned out that Ken was using a rather old JDK (1.2) which is known to have rather lousy JIT on Solaris platform. I have already recommended Ken to upgrade both the JDK and the HttpClient Cheers Oleg On Wed, 2003-03-26 at 17:10, Tom Samplonius wrote: What version of httpclient are you using? I understand that a busy read loop was removed from httpclient a couple of weeks ago. I'm not sure if this change was made for Alpha3, or whether you have to go the daily builds to get it. Tom On Wed, 26 Mar 2003, Ken Clark wrote: I've built a b2b application using the commons HttpClient, and all works extremely well. The problem is, however, that the app is using up to 45% of the CPU time ( as reported by various unix processes ( ps -aux, vmstat, etc ) ). The customer has a Sun 4500, running solaris, with two processors. I've tried debugging the app's CPU usage using the -Xrunhprof:cpu=samples parameter in the VM, and it returns the hot spots for CPU usage : 1 74.67% 74.67% java/net/SocketInputStream.read ([BII)I 2 9.61% 84.28% java/net/PlainSocketImpl.available ()I 3 8.51% 92.79% java/net/PlainSocketImpl.doConnect (Ljava/net/InetAddress;I)V everything else is using less than 0.50% of the VMs CPU. Since I'm not using these classes directly, I'm assuming that HttpClient is. How can I make my app use less of the CPU? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 connection. At the moment HttpClient simply raises a HttpRecoverableException and let the caller deal with it 2. Since you appear to be handling the multithread synchronization by yourself, anyway, it may make sense to use SimpleHttpConnectionManager instead of MultiThreadedConnectionManager Again, Mike Becke is the man to comment of connection pooling related stuff. I hope he'll correct me if I err on any of these accounts. Apparently since the way MultiThreadedConnectionManager handles stale connections seems to irritate quite a few folks out there, something needs to be done about it Cheers Oleg -Original Message- From: Thiago Costa [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 00:03 To: [EMAIL PROTECTED] Subject: MultiThread Dear Friends, I'm using the HTTP Client in a pool of connection. I have created a class that manage a list of URL. For example: i have a list of 100 URLs of diferent hosts. I want to retrieve all this urls but i don't want to do this in a sequencial mode. I want to put some connections in a paralel mode. Like for example... I want 10 connection in paralel... Then, when a connection finish an other starts. I want to use this in a meta engine to retrive documents in Web. My problem is that httpclient is raising many exeptions of connection timeout. I'm running my application in super fast internet provider and it's not normal these time outs. Does the httpclient manage a pool of connection like that ? Does httpclient works well in a multithead mode ? How can i manage a list of url with a great performance ? Can you help-me? Thanks very much Thiago Costa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. Preferably the example will use JDK1.4 but examples that use earlier versions are also much appreciated. Regards Max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 order to allow for authentication against an HTTP server with self-signed certificate. You are likely to have to follow the same pattern: provide a custom X509TrustManager and a custom ProtocolSocketFactory. Oleg -Original Message- From: Max Johnson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2003 12:07 To: [EMAIL PROTECTED] Subject: 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. Preferably the example will use JDK1.4 but examples that use earlier versions are also much appreciated. Regards Max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 i´m wrong? I want to understand the MultiThreadedConnectionManager. Can MultiThreadedConnectionManager do what i want ? Can it manage a set of connections ? If yes, where can i find an example ? Thanks very much. Waiting for response, Thiago Costa Citando Kalnichevski, Oleg [EMAIL PROTECTED]: 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 connection. At the moment HttpClient simply raises a HttpRecoverableException and let the caller deal with it 2. Since you appear to be handling the multithread synchronization by yourself, anyway, it may make sense to use SimpleHttpConnectionManager instead of MultiThreadedConnectionManager Again, Mike Becke is the man to comment of connection pooling related stuff. I hope he'll correct me if I err on any of these accounts. Apparently since the way MultiThreadedConnectionManager handles stale connections seems to irritate quite a few folks out there, something needs to be done about it Cheers Oleg -Original Message- From: Thiago Costa [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 00:03 To: [EMAIL PROTECTED] Subject: MultiThread Dear Friends, I'm using the HTTP Client in a pool of connection. I have created a class that manage a list of URL. For example: i have a list of 100 URLs of diferent hosts. I want to retrieve all this urls but i don't want to do this in a sequencial mode. I want to put some connections in a paralel mode. Like for example... I want 10 connection in paralel... Then, when a connection finish an other starts. I want to use this in a meta engine to retrive documents in Web. My problem is that httpclient is raising many exeptions of connection timeout. I'm running my application in super fast internet provider and it's not normal these time outs. Does the httpclient manage a pool of connection like that ? Does httpclient works well in a multithead mode ? How can i manage a list of url with a great performance ? Can you help-me? Thanks very much Thiago Costa
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 first request did not reach the server. For example imagine im performing some sort of request to a remote machine through http, this request must be unique and cannot be duplicated. Can i be fully sure that the first request did not reach the server if i get the recoverable error? Thanks. Sergio.
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 of request being successfully processed by the server, but client failing to receive the response. Your application design has to take this problem into consideration. Oleg -Original Message- From: Sergio Berna [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2003 13:32 To: [EMAIL PROTECTED] Subject: 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 first request did not reach the server. For example imagine im performing some sort of request to a remote machine through http, this request must be unique and cannot be duplicated. Can i be fully sure that the first request did not reach the server if i get the recoverable error? Thanks. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 the server side (due to inactivity) writing to it causes and IOException (in 1.4.1 it is a SocketException). This is important because SocketExceptions are considered recoverable where IOExceptions are not. So this error will not show up on some JREs as it will get treated as a recoverable exception and will be handed by the HttpMethod. This brings up a few questions: 1) should we de differentiating between SocketExceptions and IOExceptions? 2) is there some other more reliable way to determine if a connection is closed? Also, this error points out a bug in HttpConnection. When an IOException occurs on a connection the method fails but the connection is never closed or marked as unusable. Therefore is keeps getting reused even though it will always throw an IOException. This is not a problem in the case of SocketExceptions as the connection gets reopened by the method. It seems to me that the HttpConnection should probably be closing itself when any exception occurs during writing (maybe reading too). What do others think? Sergio. To fix this problem for the short term I would suggest either using HTTP 1.0 or a JRE that does not exhibit this problem. Using HTTP 1.0 will cause the connections to not be reused (call HttpMethod.setHttp11(false) ). Using a 1.4.1 (at least for me) will cause recoverable exceptions that will get handed by the method. Any other thoughts on this would be appreciated. Thanks, Mike On Wednesday, March 26, 2003, at 02:11 PM, Sergio Berna wrote: I have been trying to build a small piece of code that could reproduce this bug, the problem is that im executing this inside a weblogic server and i have not been able to reproduce the same behavior on the client. At the client i find the cant read HTTP/ message after some time on second connection(over 15 seconds) but retrying does work. At the server it is the broken pipe one and no matter the amount or times i retry it is always the same message. As soon is as i have a working class able to reproduce the error ill send it, meanwhile im attaching the class im using in case im doing something stupid and havent realized. Thanks for your time. Sergio. -Mensaje original- De: Michael Becke [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 26 de marzo de 2003 19:09 Para: Commons HttpClient Project Asunto: Re: connections on pool close unexpectedly I do not think this is the problem Sergio is having. He seems to be having problems with connections becoming unusable, not having to many open connections. We shall see though. Sergio, please let us know when you have more details so we can help you get to the bottom of this. Thanks, Mike Carl A. Dunham wrote: Sergio, I had posted a crude patch a few days ago that partially solves this problem. It basically adds a wider connection pool that tracks free connections, closing them when needed and blocking requests in order to maintain a maximum number of open connections. It is better, but still not quite right. Maybe it'll help you... BTW, I'm not an httpclient developer, just a user trying to solve my own problems... Carl On Tuesday March 25 2003 12:45, Sergio Berna wrote: Just one more question then, before ill try to correct it myself, im assuming that the connections are been pooled inside the multhreadedmanager so as to improve performance. The only problem im facing is that the manager doesnt realize the connection is broken and i cant find any method to tell it, so the connection is forever broken at the pool and no matter the attemps i do it is always used first with the expected failure. Is there any method to expire the connection fotever or should i always create a new HttpClient so that i can use a new pool? If it doesnt i could try solving this problem by automatically deleting a connection which had thrown an IOException (then a reconnect would work) or making a method to expunge it out of the pool. The last one is tricky since you cant use it with the responsebody methods. Which one do you suggest? Sergio. -Mensaje original- De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Enviado el: martes, 25 de marzo de 2003 18:36 Para: Commons HttpClient Project Asunto: Re: connections on pool close unexpectedly Sergio I regret that your message has been left unanswered for so long. The problem is that out of 4 committers I seem to be the only one currently monitoring this forum on a regular basis, and I just happened to not be using connection pooling much. So, I am not the best source to turn to in this regard. You'll have to wait until Mike gets back in order to get a more informed opinion on
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 -- Client OS -- HTTP -- Server OS -- HttpServer -- Server application. So far as you know, any one of these layers could consume your request, or the response, and fail to deliver the response processed message back to your client. At least, if you're really being paranoid, you need to worry about this. If you want to insure that the server application processes a request at most once, then put a unique number into each request, and the server should check that that number does not match any earlier requests. Of course, the server would need to reject any request without a unique number. It might be possible to approximate your need by a change to HttpClient. Right now, it doesn't guarantee when a recoverable exception gets thrown. It could, for example, be thrown before writing the body of any request - in which case you would have your iron-clad guarantee that server did not get the request. That could be a sufficient level of protection for what you need. Is it? -Eric. Sergio Berna wrote: 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 first request did not reach the server. For example imagine im performing some sort of request to a remote machine through http, this request must be unique and cannot be duplicated. Can i be fully sure that the first request did not reach the server if i get the recoverable error? Thanks. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 way. Thx. -Mensaje original- De: Eric Johnson [mailto:[EMAIL PROTECTED] Enviado el: jueves, 27 de marzo de 2003 15:09 Para: Commons HttpClient Project Asunto: 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 -- Client OS -- HTTP -- Server OS -- HttpServer -- Server application. So far as you know, any one of these layers could consume your request, or the response, and fail to deliver the response processed message back to your client. At least, if you're really being paranoid, you need to worry about this. If you want to insure that the server application processes a request at most once, then put a unique number into each request, and the server should check that that number does not match any earlier requests. Of course, the server would need to reject any request without a unique number. It might be possible to approximate your need by a change to HttpClient. Right now, it doesn't guarantee when a recoverable exception gets thrown. It could, for example, be thrown before writing the body of any request - in which case you would have your iron-clad guarantee that server did not get the request. That could be a sufficient level of protection for what you need. Is it? -Eric. Sergio Berna wrote: 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 first request did not reach the server. For example imagine im performing some sort of request to a remote machine through http, this request must be unique and cannot be duplicated. Can i be fully sure that the first request did not reach the server if i get the recoverable error? Thanks. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 exception raised (handshake, header, body, etc). At least i think the connection already closed error which is one of the most frequent ones while working with a cache pool should have a preferential order in the list because it is the preferred HttpClient way of reusing connections. What do you think? Sergio. -Mensaje original- De: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Enviado el: jueves, 27 de marzo de 2003 16:30 Para: Commons HttpClient Project Asunto: 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 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 way. Thx. -Mensaje original- De: Eric Johnson [mailto:[EMAIL PROTECTED] Enviado el: jueves, 27 de marzo de 2003 15:09 Para: Commons HttpClient Project Asunto: 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 -- Client OS -- HTTP -- Server OS -- HttpServer -- Server application. So far as you know, any one of these layers could consume your request, or the response, and fail to deliver the response processed message back to your client. At least, if you're really being paranoid, you need to worry about this. If you want to insure that the server application processes a request at most once, then put a unique number into each request, and the server should check that that number does not match any earlier requests. Of course, the server would need to reject any request without a unique number. It might be possible to approximate your need by a change to HttpClient. Right now, it doesn't guarantee when a recoverable exception gets thrown. It could, for example, be thrown before writing the body of any request - in which case you would have your iron-clad guarantee that server did not get the request. That could be a sufficient level of protection for what you need. Is it? -Eric. Sergio Berna wrote: 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 first request did not reach the server. For example imagine im performing some sort of request to a remote machine through http, this request must be unique and cannot be duplicated. Can i be fully sure that the first request did not reach the server if i get the recoverable error? Thanks. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 socketchannels and shared buffers would be the best way of creating a multithreaded connection manager. Have you had any discussion about this? Thx for your time. Sergio.
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 time frame, together with redirect logic redesign. Feel free to file a bug report, so we do not overlook this problem in the future Oleg On Thu, 2003-03-27 at 18:00, Sergio Berna wrote: 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 exception raised (handshake, header, body, etc). At least i think the connection already closed error which is one of the most frequent ones while working with a cache pool should have a preferential order in the list because it is the preferred HttpClient way of reusing connections. What do you think? Sergio. -Mensaje original- De: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Enviado el: jueves, 27 de marzo de 2003 16:30 Para: Commons HttpClient Project Asunto: 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 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 way. Thx. -Mensaje original- De: Eric Johnson [mailto:[EMAIL PROTECTED] Enviado el: jueves, 27 de marzo de 2003 15:09 Para: Commons HttpClient Project Asunto: 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 -- Client OS -- HTTP -- Server OS -- HttpServer -- Server application. So far as you know, any one of these layers could consume your request, or the response, and fail to deliver the response processed message back to your client. At least, if you're really being paranoid, you need to worry about this. If you want to insure that the server application processes a request at most once, then put a unique number into each request, and the server should check that that number does not match any earlier requests. Of course, the server would need to reject any request without a unique number. It might be possible to approximate your need by a change to HttpClient. Right now, it doesn't guarantee when a recoverable exception gets thrown. It could, for example, be thrown before writing the body of any request - in which case you would have your iron-clad guarantee that server did not get the request. That could be a sufficient level of protection for what you need. Is it? -Eric. Sergio Berna wrote: 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 first request did not reach the server. For example imagine im performing some sort of request to a remote machine through http, this request must be unique and cannot be duplicated. Can i be fully sure that the first request did not reach the server if i get the recoverable error? Thanks. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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, 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 socketchannels and shared buffers would be the best way of creating a multithreaded connection manager. Have you had any discussion about this? Thx for your time. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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] Enviado el: jueves, 27 de marzo de 2003 18:32 Para: Commons HttpClient Project Asunto: 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, 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 socketchannels and shared buffers would be the best way of creating a multithreaded connection manager. Have you had any discussion about this? Thx for your time. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 folks out there. There are numerous limitations of the current architecture we can't work around (at least nicely). Our strategy is to release 2.0 as soon as the existing HttpClient is reasonably stable and bug-free and move past current API compatibility where we would have a chance to improve the overall design Cheers Oleg On Thu, 2003-03-27 at 18:49, Sergio Berna wrote: 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] Enviado el: jueves, 27 de marzo de 2003 18:32 Para: Commons HttpClient Project Asunto: 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, 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 socketchannels and shared buffers would be the best way of creating a multithreaded connection manager. Have you had any discussion about this? Thx for your time. Sergio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16861. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16861 Digest Authentication fails with Microsoft ISA, appears hung to user [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 21:20 --- *** This bug has been marked as a duplicate of 17884 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884 Multiple DIGEST authentication attempts with same credentials [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 21:20 --- *** Bug 16861 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884 Multiple DIGEST authentication attempts with same credentials [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 21:22 --- Patch applied - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10817 Provide more Example Code [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 21:29 --- Patch committed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439 Unusual Http status line Summary: Unusual Http status line Product: Commons Version: 2.0 Alpha 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The web server at http://alces.med.umn.edu/Candida.html returns the following status line: HTTP 200 Document follows This page loads in the 3 browsers I tried (though Safari actually rendered the headers). The current version of HttpClient reads through the whole page looking for a line that starts with HTTP/. I don't know how big of a problem this is, but it's a fairly easy fix. Patch to follow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439 Unusual Http status line --- Additional Comments From [EMAIL PROTECTED] 2003-03-28 03:18 --- Created an attachment (id=5551) FIX - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 Follows rather than OK for the response text, but that is acceptable. The version number is in there and correctly formatted. Can we really blame the strange behaviour we are seeing on the server? Jandalf. [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439 Unusual Http status line Summary: Unusual Http status line Product: Commons Version: 2.0 Alpha 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The web server at http://alces.med.umn.edu/Candida.html returns the following status line: HTTP 200 Document follows This page loads in the 3 browsers I tried (though Safari actually rendered the headers). The current version of HttpClient reads through the whole page looking for a line that starts with HTTP/. I don't know how big of a problem this is, but it's a fairly easy fix. Patch to follow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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 Follows rather than OK for the response text, but that is acceptable. The version number is in there and correctly formatted. Can we really blame the strange behaviour we are seeing on the server? Jandalf. [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439 Unusual Http status line Summary: Unusual Http status line Product: Commons Version: 2.0 Alpha 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The web server at http://alces.med.umn.edu/Candida.html returns the following status line: HTTP 200 Document follows This page loads in the 3 browsers I tried (though Safari actually rendered the headers). The current version of HttpClient reads through the whole page looking for a line that starts with HTTP/. I don't know how big of a problem this is, but it's a fairly easy fix. Patch to follow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
