Re: using httpclient from tomcat
Jo, what version of Tomcat are you using? Recent Tomcats do not come with a security manager in their default configuration. Odi Johannes Huettemeister wrote: Hi, as you might notice I'm not a java professional and also my tomcat knowledge is limited. If I just create GetMethod objekt in the servlet I get a security exception. If you say that this is unusual, I guess I got an error in my tomcat configuration, I will have a close look now to this. btw: its not an applet its a very simple servlet only. cheers johannes. -- _ NOSE applied intelligence ag [www] http://www.nose.ch ortwin glück [email] [EMAIL PROTECTED] hardturmstrasse 171 [pgp key] 0x81CF3416 8005 zurich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SocketException : SSL Implementation not available
Hello, from the JavaDocs of javax.net.ssl.SSLSocketFactory.getDefault(): If SSL has not been configured properly for this virtual machine, the factory will be inoperative (reporting instantiation exceptions). In order to create SSL connections, the SSL implementation needs to know the root certificates it is supposed to trust. This must be configured, usually in properties files. Since you are switching manually to a Sun JSSE within an IBM JDK, chances are that there is no configuration of the key store, which is supposed to hold the root certificates. You should verify steps 7 and 8 of the installation instructions: http://java.sun.com/products/jsse/install.html hope that helps, Roland Ramanan nr [EMAIL PROTECTED] 24.07.2003 22:32 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject:RE: SocketException : SSL Implementation not available Hi oleg, My https call. Works fine with Sun JDK 1.4.1 I dont have the provision to move to IBM's Version I am using commons-httpclient 2.0 beta, IBM JDK 1.3.1 (WSAD 4.0.3), Sun JSSE 1.0.3 I downloaded Sun JSSE 1.0.3 added the jar files from that to WSAD JRE (to the ext directory) changed the security file to add the following info: security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.crypto.provider.SunJCE security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.jsse.JSSEProvider #security.provider.5=com.ibm.crypto.provider.IBMJCE #security.provider.6=com.ibm.jsse.JSSEProvider Also in my code I am doing the following : System.setProperty(java.protocol.handler.pkgs,com.sun.net.ssl.internal.www.protocol); Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); Security.insertProviderAt(new com.sun.crypto.provider.SunJCE(),1); I am getting the following exception: java.net.SocketException: SSL implementation not available at javax.net.ssl.DefaultSSLSocketFactory.createSocket(Unknown Source) at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:127) at org.apache.commons.httpclient.HttpConnection.tunnelCreated(HttpConnection.java:749) at org.apache.commons.httpclient.ConnectMethod.execute(ConnectMethod.java:204) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:638) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500) stacktrace removed Am I missing any thing that needs to be done? thanks NRR
DO NOT REPLY [Bug 21880] New: - Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods
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=21880. 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=21880 Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods Summary: Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods Product: Commons Version: 2.0 Beta 2 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently 'Content-Length' 'Transfer-Encoding' request headers are handled by the HttpMethodBase class. This is conceptually wrong and error-prone in my opinion. Entity enclosing methods should control 'Content-Length' 'Transfer- Encoding' request headers instead, as they provide request content and encapsulate the requisite content transfer logic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: Commons-HttpClient conflict with WebDAVClient
There should be some documentation on both projects web sites stating their 'connectedness' of lack of it... I bet I am not the only one who ended up with this problem... Regards, Daniel -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Friday, 25 July, 2003 12:50 PM To: Commons HttpClient Project Subject: Re: FW: Commons-HttpClient conflict with WebDAVClient They're two separate projects with little interaction these days. Slide depends on HttpClient and we do try our best not to break their build but I don't think there are any committers on both teams. Regards, Adrian Sutton. On Friday, July 25, 2003, at 02:30 PM, Daniel Joshua wrote: Just curious is there any co-ordination going on between the Commons-HttpClient and the Slide developers? Or are the 2 Jakarta projects developing totally independant of each other? Regards, Daniel -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 July, 2003 8:33 PM To: Commons HttpClient Project Cc: 'Slide Users Mailing List' Subject: Re: FW: Commons-HttpClient conflict with WebDAVClient There are a few options here: a. Check out the slide sources and build against HttpClient beta 2 instead of HEAD (all the compile errors that I can see are due to the changes on the HEAD branch and won't be in the 2.0 release). b. Update Slide to compile with HttpClient CVS HEAD - Note that slide will then no longer compile with older HttpClient versions. I can do up a patch if the slide developers want to do it this way. c. Release HttpClient 2.0 (planned very soon) and Slide x.x (???) then take option b. d. Something else? I'll open a bug report on this in a moment, Daniel I'd suggest you add yourself to the CC list. Regards, Adrian Sutton. On Thursday, July 24, 2003, at 10:12 PM, Daniel Joshua wrote: Can somebody make a release soon in that case... I really need a WebDAVClient which can be use with either a Commons-HttpClient beta 1 or 2? Regards, Daniel -Original Message- From: Christopher Lenz [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 July, 2003 7:53 PM To: Slide Users Mailing List Subject: Re: FW: Commons-HttpClient conflict with WebDAVClient Martin Holz wrote: Daniel Joshua [EMAIL PROTECTED] writes: We use the latest beta releases of HttpClient with a CVS build of the WebDAV client. Works fine. Fisrt, I have checked http://jakarta.apache.org/site/binindex.cgi and the latest release build for download is Slide 1.0.16. Also, I was looking at the Slide documentation and there is mention of Slide 2.0.0 Where can I download this. Slide 2.0 is not released and there is no such thing as nightly build. You have to build it from CVS. There *are* automated nightly builds: http://cvs.apache.org/builds/jakarta-slide/nightly/ But the builds have been faily for weeks now :-/ http://cvs.apache.org/builds/gump/latest/jakarta-slide.html (Apparently due to an incompatible change in HttpClient) -chris - 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] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - 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] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - 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 10791] - HTTP Version configuration and tracking
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=10791. 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=10791 HTTP Version configuration and tracking --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 13:33 --- Oleg, Very nice. I think this is a clean solution to the problem. I have a few comments: - HttpVersion.parse() no longer handles the http status of HTTP. Though this is an obviously non-standard value it is something that we intentionally added support for. - HttpVersion should implement hashCode(). - HttpVersion.equals(Object) does the following test: if ((obj != null) (obj instanceof HttpVersion)) Though this is not an error the test for null is not necessary as instanceof already handles this case. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
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=19868. 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=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 14:00 --- Created an attachment (id=7510) (Hopefully) the final exception handling clean-up (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
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=19868. 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=19868 Exception handling in HttpClient requires redesign --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 14:02 --- I cleaned up things somewhat and dealt with the remaining outstanding issues. Please let me know what you think. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21880] - Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods
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=21880. 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=21880 Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 14:30 --- Created an attachment (id=7512) Patch (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21880] - Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods
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=21880. 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=21880 Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 14:30 --- Javadoc warning corrected. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10791] - HTTP Version configuration and tracking
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=10791. 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=10791 HTTP Version configuration and tracking --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 15:29 --- Created an attachment (id=7515) HTTP version patch (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10791] - HTTP Version configuration and tracking
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=10791. 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=10791 HTTP Version configuration and tracking --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 16:05 --- I don't know of a good reason to hash HttpVersions either. I think it is just good practice to override equals() and hashCode() together. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DNS // NIO
Clemens, Please see my comments below On Fri, 2003-07-25 at 19:24, Clemens Marschner wrote: Hi, there are two issues I would like to bring up that were mentioned in this list during the last months but were never resolved: 1. Java DNS handling as done by java.net.Socket is very inefficient for snip This could be avoided by issueing only the IP address to java.net.Socket and thus to HTTPClient. However, it is necessary to pass the host name to HTTPClient in order to resolve multiple host names per IP address within the HTTP request. Do you have any plans to plug in an external DNS resolver and create a Socket only with the IP address? The issue of custom DNS resolver has been discussed on several occasions. The consensus was (if my memory does not fail me) that domain name resolution was clearly out of HttpClient's scope. Instead we have provided a way to plug in a custom DN resolution mechanism by supporting virtual host names in the target host's configuration. HostConfiguration hostconfig = new HostConfiguration(); hostconfig.setHost(127.0.0.1, www.whatever.com, 80, Protocol.getProtocol(http)); HttpClient agent = new HttpClient(); agent.setHostConfiguration(hostconfig); 2. Are there any people working on a NIO based version of HTTPClient? I saw some notes on this on a weblog, but haven't seen any results. Our goal is to provide Java 1.2 compatibility as long as the project reliant on HttpClient require it. That puts NIO support pretty much out of question for a considerable period of time to come. This said, however, we are planning to provide a means of plugging in a custom HttpConnection implementation in 3.x release, which would allow NIO based implementation to be used instead of official Java 1.2 compatible one. More good stuff will be coming in the 3.x release. It can well make bearing with us worthwhile. cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DNS // NIO
The issue of custom DNS resolver has been discussed on several occasions. The consensus was (if my memory does not fail me) that domain name resolution was clearly out of HttpClient's scope. Instead we have provided a way to plug in a custom DN resolution mechanism by supporting virtual host names in the target host's configuration. HostConfiguration hostconfig = new HostConfiguration(); hostconfig.setHost(127.0.0.1, www.whatever.com, 80, Protocol.getProtocol(http)); HttpClient agent = new HttpClient(); agent.setHostConfiguration(hostconfig); This can also be done on individual methods using HttpMethod.getHostConfiguration().setHost(...). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21880] - Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods
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=21880. 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=21880 Content-Length Transfer-Encoding request headers should be handled by entity enclosing methods [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-25 18:33 --- Patch committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Performance Issue
Hi, After upgrading from 2.0-alpha3 to 2.0-beta2, instead of roughly 10 requests per second, I am averaging only 3 requests per second. I was hoping someone could take a look at the attached code and show me the 'error of my ways.' My test is multithreaded, and all requests are sent to the same host. I am setting MaxConnectionsPerHost equivalent to the number of sending threads. The auth-method required by the server is BASIC. Thanks for your help. Todd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
