Re: Problem with Basic Authentification and non ASCII characters
Hi Mike,
your quick and easy patch fixes the problem right away. For my problem it
is good to go!
Thanks for the quick response and solution.
Olaf
P.S. Using UTF-8 does no good, I had tried this before.
Michael Becke [EMAIL PROTECTED] wrote on 13.11.2003 03:59:43:
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,
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 basic authentification, but authentification
failed because of the non ASCII characters.
We used the password ä-ö-ü for testing and it turned out that
HTTPClient
translates this to ZGg6Py0/LT8=. Internet Explorer and Mozilla
translates
this to ZGg65C32Lfw=. Using
org.apache.commons.httpclient.util.Base64.decode with the wrong string
results in ?-?-? where the second string results in the correct
ä-ö-ü,
so encode and decode are not symetric.
Using the code below (I found some time ago on the internet) to
translate
the password into the base64 version results in the correct string.
For me the question is, if a password with non ASCII characters is not
allowed at all (in the HTTPClient documentation I could not find a
hint in
this direction or I have missed it), but even if not, browsers seem to
support it, so the used Base64-encoding class seems to be bugy and
should
be fixed in 2.0, before it is completely replaced for 2.1.
Any thoughts or hints are welcome.
Regards,
Olaf
public class Base64
{
static String BaseTable[] = {
A, B, C, D, E, F, G, H, I, J, K, L, M,
N,
O, P,
Q, R, S, T, U, V, W, X, Y, Z, a, b, c,
d,
e, f,
g, h, i, j, k, l, m, n, o, p, q, r, s,
t,
u, v,
w, x, y, z, 0, 1, 2, 3, 4, 5, 6, 7, 8,
9,
+, /
};
public static String encode(String text) {
int n = text.length();
if (n 1)
return text; // no bytes to encode!?!
StringBuffer output = new StringBuffer(n);
// read the entire file into the byte array
byte bytes[] = new byte[ (n)];
bytes = text.getBytes();
byte buf[] = new byte[4]; // array of base64 characters
int n3byt = n / 3; // how 3 bytes groups?
int nrest = n % 3; // the remaining bytes from the grouping
int k = n3byt * 3; // we are doing 3 bytes at a time
int linelength = 0; // current linelength
int i = 0; // index
// do the 3-bytes groups ...
while (i k) {
buf[0] = (byte) ( (bytes[i] 0xFC) 2);
buf[1] = (byte) ( ( (bytes[i] 0x03) 4) |
( (bytes[i + 1] 0xF0) 4));
buf[2] = (byte) ( ( (bytes[i + 1] 0x0F) 2) |
( (bytes[i + 2] 0xC0) 6));
buf[3] = (byte) (bytes[i + 2] 0x3F);
output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]).append(
BaseTable[buf[2]]).append(BaseTable[buf[3]]);
if ( (linelength += 4) = 76) {
output.append(\r\n);
linelength = 0;
}
i += 3;
}
// deals with with the padding ...
if (nrest == 2) {
// 2 bytes left
buf[0] = (byte) ( (bytes[k] 0xFC) 2);
buf[1] = (byte) ( ( (bytes[k] 0x03) 4) |
( (bytes[k + 1] 0xF0) 4));
buf[2] = (byte) ( (bytes[k + 1] 0x0F) 2);
}
else if (nrest == 1) {
// 1 byte left
buf[0] = (byte) ( (bytes[k] 0xFC) 2);
buf[1] = (byte) ( (bytes[k] 0x03) 4);
}
if (nrest 0) {
// send the padding
if ( (linelength += 4) = 76)
output.append(\r\n);
output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]);
// Thanks to R. Claerman for the bug fix here!
if (nrest == 2) {
output.append(BaseTable[buf[2]]);
}
else {
output.append(=);
}
output.append(=);
}
return output.toString();
}
}
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail: commons-httpclient-dev-
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies, Chunked-Post Threads
Hello Sven, browsers make requests in parallel for *one* user! Meaning that all the cookies returned end up in the same cookie store, as they do here. A proxy servlet will make requests for different users (browsers) and therefore has to maintain a different state for each user. That state is typically associated with the session between the browser and servlet. I have rewritten our own proxy servlet to optionally use the HTTP Client instead of the HttpURLConnection, and I didn't encounter problems with parallel requests by now. Which could also indicate that I didn't have enough time to test it thoroughly yet :-) Anyway, I handle cookie and set-cookie headers manually and use a single state object that does never store any cookies. And when manually handling the cookies, I use a CookieBox class that gets instantiated once for each session. It's either that, or different state objects for each session. But you can't just throw all cookies returned for all users into a single state and expect the HTTP client to figure out which cookie belongs to which user. regards, Roland Sven Köhler [EMAIL PROTECTED] 12.11.2003 15:40 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Cookies, Chunked-Post Threads 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 remember seeing some synchronized statements in there. Anyway, except for storing cookies, it is accessed read-only. Well, it's a that odd application of the HttpState-Object since every browser makes multiple requests to a server in parrallel. So this would be a feature i would request. Well, most methods of HttpState seem to be synchronized, but as i already mentioned, it's pretty easy to easy to solve any bad mix-up. What i don't want is to serialize (meaning executing one after another) the HTTP-Requests. I want them to execute in parralel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Basic Authentification and non ASCII characters
[EMAIL PROTECTED] wrote: byte bytes[] = new byte[ (n)]; bytes = text.getBytes(); Bravo, the above code couldn't be worse... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.NoClassDefFoundError: javax/crypto/NoSuchPaddingExcepti on
Khalid Ishaque wrote: 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??? Please post the stack trace. I am sure this is coming from the underlying SSL implementation which may not be suitable for 1.3. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24671] - Basic Authentification fails with non-ASCII username/password characters
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-11-13 03:03 ---
Created an attachment (id=9084)
Patch 1
+int[] germanChars = { 0xE4, 0x2D, 0xF6, 0x2D, 0xFc };
+StringBuffer buffer = new StringBuffer();
+for (int i = 0; i germanChars.length; i++) {
+buffer.append((char)germanChars[i]);
+}
that is nicely US safe, Mike :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies, Chunked-Post Threads
browsers make requests in parallel for *one* user! Meaning that all the cookies returned end up in the same cookie store, as they do here. A proxy servlet will make requests for different users (browsers) and therefore has to maintain a different state for each user. That state is typically associated with the session between the browser and servlet. I maintain a HttpState-Object for each Session the Servlet sees. It's either that, or different state objects for each session. But you can't just throw all cookies returned for all users into a single state and expect the HTTP client to figure out which cookie belongs to which user. Sorry, it seems we missunderstood each other. I never wanted to put all in one HttpState-Object. My intention was to maintain one CookieBox per Session and that's what i do with the HttpState-Objects at the moment. Everything works fine now. Thanks for your help. Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve 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=24560. 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=24560 HttpClient loops endlessly while trying to retrieve status line --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 13:27 --- Created an attachment (id=9093) Simple, generic HTTP Server; used TestBadContentLength as example - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve 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=24560. 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=24560 HttpClient loops endlessly while trying to retrieve status line --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 13:40 --- Oleg, thank you for compliments :) I also think that it is quite important for a HTTP client to have a bundled, tiny HTTP server for testing. Unfortunately, at the moment, I do not have the time to dig that deep into HttpClient's test cases. However, I provide a simple HTTP server framework, where you can construct the replies yourselves (anyone interested in?) By default, the SimpleHttpServer does nothing but throwing a 503 Service Unavailable until you extend it with your own request handlers. One is provided in the new TestBadContentLength. Another one is a handler chain, where multiple handlers can be stacked up, even to very complex structures (chains of chains). The chain stops on the first handler that writes to the given output stream. By the way: It is not very well tested, just give it a try. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.NoClassDefFoundError: javax/crypto/NoSuchPaddingExcepti on
Hello Khalid, My guess is that you're using NTLM authentication. NTLM require the JCE to work. JCE is included in 1.4 JVMs but not in 1.3.1. You will need to include the JCE jars and initialize it correctly for NTLM to work. Mike Ortwin Glück wrote: Khalid Ishaque wrote: 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??? Please post the stack trace. I am sure this is coming from the underlying SSL implementation which may not be suitable for 1.3. Odi - 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]
URI with nn.nn.nn.nn:nn parses port but not with xx.net:nn
I'm using HttpClient-2.0rc2. I'm testing some code that makes an external URL connection. I'm testing it with two possible URLs, but they only differ by the host name and possibly the specified port. This is probably just a continuation of some earlier issues I was having because of my need to install an alternate socket factory. One URL uses a raw IP address and a specific port, like nn.nn.nn.nn:nn. When I create the PostMethod with this URL, then get the URI from the method, and then read the port, I find it's found the correct port. However, I have two problems with the other URL. I first tried it without a specific port, using the default. This creates a problem because my connection eventually fails because I end up using a port value of -1. This is probably because I end up using a block of code like this: method.getHostConfiguration(). setHost(uri.getHost(), uri.getPort(), newProtocol); Apparently, the port value in the URI is -1. I'm not sure how to solve this. So, I then tried changing the second URL to include a specific port number, like host.net:443. Strangely enough, this ends up generating the same error. I tried stepping the HttpMethodBase constructor (which I send my URL to), and I found that after it parsed the URI, it didn't think there was a specified port number. When I stepped through the same code with the first URL (using the IP address), it was able to find the port number. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24504] - Cannot create a document that has accent characters (Latin) in it's name
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=24504. 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=24504 Cannot create a document that has accent characters (Latin) in it's name [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve 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=24560. 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=24560 HttpClient loops endlessly while trying to retrieve status line [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|NEW |ASSIGNED Priority|Other |Low Target Milestone|--- |2.1 Beta 1 --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 19:05 --- Christian, I finally found enough time to thoroughly examine your patch. While OK in general there were a few minor details that I did not quite like: - Throwing a protocol exception from ResponseConsumedWatcher#responseConsumed was not such a good idea after all. I think it requires too much of ugly code for very little (or none at all) practical gains. In my version of the patch extra response content results in a warning message. No exception is thrown. - HTTP spec requires that HTTP agents ignore all blank lines that precede the response status line. In your patch is was not taken into consideration - I adjusted the new parameters to be more in line with existing parameter conventions in HttpClient Bottom line, I did go a bit rough on your patch. Please let me know if these changes are OK with you or not. If there’s something you do not quite agree with, let me know I'll take a closer at your simple HTTP Server stuff a bit later. I am quite determined to replace the existing SimpleHttpConnection testing framework with a new one based on your code. Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve 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=24560. 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=24560 HttpClient loops endlessly while trying to retrieve status line --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 19:09 --- Created an attachment (id=9095) Patch (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24671] - Basic Authentification fails with non-ASCII username/password characters
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24671 Basic Authentification fails with non-ASCII username/password characters [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |2.0 Final --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 19:18 --- +1 to check the patch in Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keeping Connections Alive
Hi All, I'd like to clarify a point about HttpClient that I do not fully understand. How/when does the actual connection to a server close? I understand that MultiThreadedHttpConnectionManager (and possibly SimpleConnectionManager as well) will keep the connection alive and reuse it for subsequent HTTP requests. Is there a way to set a limit on how long the connection should be kept alive before waiting for a subsequent request to reuse that connection? Thanks, Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SSL-Connection to unstrusted host
On Wed, 2003-11-12 at 17:24, Aaron Williams wrote: 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 began getting the SSLHandshakeException. This occurred with no changes on the client side. Aaron, it all sounds a bit fishy to me. To my best knowledge SSLHandshakeException (Could not find the trusted certificate) thrown only in case of the target server's certificate having been signed with a untrusted certificate. This is highly improbable that a certificate would once of a sudden become untrusted (As far as I know JSSE does not currently provide support for certificate revocation lists). So, the problem could possibly indicate one of those: - corruption of local certificate store (not impossible, but unlikely) - the server certificate signed with a trusted root certificate has been replaced with a self signed certificate. In the latter case the EasySSLProtocolSocketFactory should do the trick. However, I would encourage you not to copy in blindly, but rather take it as a starting point and customise its functionality to better match the requirements of your particular application. Hope this helps somewhat Oleg We do have the lines Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); host.setHost(hostname, port, https); client.setHostConfiguration(host); Before we create PostMethod() Here is the thrown exception javax.net.ssl.SSLHandshakeException: Could not find the trusted certificate at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.ClientHandshaker.a(DashoA6275) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(DashoA6275) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1351) at java.io.BufferedOutputStream.flushBuffer(Unknown Source) at java.io.BufferedOutputStream.flush(Unknown Source) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht tpConnection.java:779) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase .java:2257) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa se.java:2629) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1085) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 74) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 29) Can anyone help with this? Would using EasySSLProtocolSocketFactory class fix this error? Thanks, Aaron -Original Message- From: Marcus Crafter [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 8:43 AM To: Commons HttpClient Project Subject: Re: SSL-Connection to unstrusted host H Sven, Roland, There's an example socket factory available on the website: http://jakarta.apache.org/commons/httpclient/sslguide.html Have a look for the EasySSLProtocolSocketFactory class. Hope that helps. Cheers, Marcus On Wed, 2003-11-12 at 15:34, Roland Weber wrote: 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 few months, so you're likely to find sample code somewhere. See interface SecureProtocolSocketFactory and class Protocol (method registerProtocol) to get started. regards, Roland Sven Köhler [EMAIL PROTECTED] 12.11.2003 15:10 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:SSL-Connection to unstrusted host 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 com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at
DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
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=24352. 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=24352 NLTM Proxy and basic host authorization [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 22:25 --- Patch committed to CVS HEAD Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve 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=24560. 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=24560 HttpClient loops endlessly while trying to retrieve status line --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 22:34 --- Created an attachment (id=9096) Patch (take 3) Contains a minor bug fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24504] - Cannot create a document that has accent characters (Latin) in it's name
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=24504. 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=24504 Cannot create a document that has accent characters (Latin) in it's name --- Additional Comments From [EMAIL PROTECTED] 2003-11-14 00:36 --- My fault, by document I was refering to file (physical file onthe hard drive) ie : c:\work\DocumentDeTèst.txt -- This filename has an accent. I am using the latest version : 2.0 Rc2 As to getAsciiBytes method, as its name implies it is supposed to return ASCII characters only. So, the behaviour of the method is correct. Precisly, but because of that the accent based charaters are converted to ? ie : c:\work\DocumentDeTèst.txt -- c:\work\DocumentDeT?st.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpMethodBase.releaseConnection() finished download
Hi, it seems that releaseConnection finishes the http-download until it is complete. I don't want that. I'm looking for a way to close the HttpConnection if the download wasn't completed yet. I'm aware that one cannot abort a Http-Transfer without closing the connection and therfor loosing it for keep-alive etc. There doens't seem to be a way of closing the HttpConnection by using the HttpMethodBase-Object. What should i try next? Thx Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping Connections Alive
Hi Sam, HttpClient does not do any active connection reclaiming, except when the resources are reused. In the case of the SimpleHttpConnectionManager the connection is never closed/reopened unless it is required for a new method execution. The case for MultiThreadedHttpConnectionManager is similar though a little more complicated. It keeps a pool of connections with a per-host and total connection limit. Again these connections are never closed until a request for a new connection warrants it. Mike On Nov 13, 2003, at 4:10 PM, Sam Berlin wrote: Hi All, I'd like to clarify a point about HttpClient that I do not fully understand. How/when does the actual connection to a server close? I understand that MultiThreadedHttpConnectionManager (and possibly SimpleConnectionManager as well) will keep the connection alive and reuse it for subsequent HTTP requests. Is there a way to set a limit on how long the connection should be kept alive before waiting for a subsequent request to reuse that connection? Thanks, Sam - 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]
