Hello Sven,
1. Cookie Container:
Let every session use it's own HttpState object. That's where
HTTP Client stores it's cookies. The only problem is that it's
not serializable, so it won't work with persistent sessions.
2. Thread Safety:
HTTP Client is thread safe as long as you use a thread safe
Mike,
in the test case I would rather introduce a Thread.sleep AFTER the
System.gc() call as well to give the GC time to run. GC happens
asynchronously. The System.gc() call is not blocking!
Odi
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24309
--- Additional Comments From [EMAIL
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
HttpClient.executeMethod
(HostConfiguration, HttpMethod, HttpState)
If you have used the same client from different
threads without specifying different states, that
might be a problem.
Well, i use this method now from different thread with different
HttpStates. I'd like to use even one
Odi,
This is a curiosity, I agree.
I take this documentation from System.gc() at face value:
When control returns from the method call, the Java Virtual Machine
*has* made a best effort to reclaim space from all discarded objects.
(emphasis added) - In other words, it is blocking, although
Well, the subject says it all:
I'd like to connect to a host with an untrusted SSL-certfictate. When
trying to connect, i always get the following exception:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException:
No trusted certificate found
at
Hello Sven,
unless you have taken special precautions, the state object
is used to store cookies. Using the same state from different
threads can mix up the cookies from different clients pretty
badly.
Once you have the cookie problem solved, there is no issue
with using the same state object. I
Hello Sven,
you will have to register your own secure socket factory.
In that factory, you can establish SSL connections without
verifying certificates. Alas, I don't remember whether such
code is included in the examples or has been posted to the
mailing list. But the topic itself pops up every
unless you have taken special precautions, the state object
is used to store cookies. Using the same state from different
threads can mix up the cookies from different clients pretty
badly.
Once you have the cookie problem solved, there is no issue
with using the same state object. I dimly
I've also recently been getting this error and was hoping someone could
shed some light on it.
We're using the RC2 version of HttpClient and our JDK versions are all
1.4 or greater. The client we are connecting to seems to have a
Verisign certificate. Initially our client worked, but we later
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I just a comment about GC. Libraries that call for GCs are not very
application friendly. When a library that is a small part of an application
explicitly invokes GCs, it can have a dramatic effect on the performance of
the whole application. This must have been seen as a common problem,
Hi,
today an administrator reported a password related problem within one of
our applications to me. I tracked down the problem that the user had used
the german Umlaute äöü in his password.
Our application tried to log in to another web site using a get method from
HTTPClient 2.0 rc2 setting
When I use JDK1.4 every thing works fine, but the second I switch to JDK
1.3.1, I get the java.lang.NoClassDefFoundError:
javax/crypto/NoSuchPaddingException error. Any suggestions???
Thanks
--Khalid
This would appear to be a character encoding issue.
In BasicScheme.authenticate, it currently does this:
return Basic + HttpConstants.getAsciiString(
Base64.encode(HttpConstants.getBytes(buffer.toString(;
I suspect it should be doing something like this:
return Basic +
Hello Olaf,
Here's a quick patch that fixes the immediate problem. From reading
RFC 2616 and 2617 it seems to me that we should have been using
ISO-8859-1 as the encoding instead of US-ASCII. Please give this patch
a try.
Mike
On Nov 12, 2003, at 3:32 PM, [EMAIL PROTECTED] wrote:
Hi,
As per usual the patch was stripped. I will attach it to bugzilla.
Mike
On Nov 12, 2003, at 9:59 PM, Michael Becke wrote:
Hello Olaf,
Here's a quick patch that fixes the immediate problem. From reading
RFC 2616 and 2617 it seems to me that we should have been using
ISO-8859-1 as the
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=24671.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24671.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
21 matches
Mail list logo
