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 --- Additional Comments From [EMAIL PROTECTED] 2003-12-10 08:34 --- I would prefer to keep them separate. Though I think the majority of the cases will only use HTTP_ELEMENT_CHARSET, I can definitely imagine a case where the credentials would require a different charset than the headers. I know that in some server configurations authorization is handled separately from other content. What do you think? My only concern is that imcompatible HTTP_ELEMENT_CHARSET and CREDENTIAL_CHARSET may (potentially) break Digest authentication. However, this is nothing more than guessing on my part, so I certainly do not mind keeping CREDENTIAL_CHARSET. +1 from me to be committed Oleg - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-12-10 13:42 --- My only concern is that imcompatible HTTP_ELEMENT_CHARSET and CREDENTIAL_CHARSET may (potentially) break Digest authentication. However Yes, you are correct. There is a potential problem with digest if the username charset is not compatible with the element charset. The DigestScheme Javadocs have a comment regarding this. I will apply the patch tonight. Mike - 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|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-11 02:49 --- Patch applied. Mike - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 14:47 --- Mike, Just a few ideas: * I think the parameter list of the AuthScheme#authenticate method is getting a bit too complex. Initially when designing AuthScheme interface I wanted to avoid its tight coupling with HttpMethod interface. However, since there seems to be no way around passing HttpMethod parameters to AuthScheme objects, I see no reason for simply not taking HttpMethod interface as input which would also give us access to method's path and method name information So, how about this? AuthScheme#authenticate(Credentials credentials, HttpMethod method) throws AuthenticationException; * EncodingUtil renders HttpConstants superfluous. HttpConstants begs to be deprecated and EncodingUtil should be used consistently throughout HttpClient base instead. Keeping both classes makes things unnecessarily confusing. * I feel HTTP_ELEMENT_CHARSET can simply be used instead of CREDENTIAL_CHARSET. Otherwise +1 from me Oleg - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-12-10 00:40 --- So, how about this? AuthScheme#authenticate(Credentials credentials, HttpMethod method) throws AuthenticationException; I agree I think that is much better. I will make the change. * EncodingUtil renders HttpConstants superfluous. HttpConstants begs to be deprecated and EncodingUtil should be used consistently throughout HttpClient base instead. Keeping both classes makes things unnecessarily confusing. Yes, HttpConstants has become a little useless. Once this patch has been applied I will take this on as a separate task. * I feel HTTP_ELEMENT_CHARSET can simply be used instead of CREDENTIAL_CHARSET. I would prefer to keep them separate. Though I think the majority of the cases will only use HTTP_ELEMENT_CHARSET, I can definitely imagine a case where the credentials would require a different charset than the headers. I know that in some server configurations authorization is handled separately from other content. What do you think? Mike - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-12-10 03:28 --- Created an attachment (id=9479) patch 2 - encoding HEAD - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 03:44 --- Attached above are two patches. One that makes ISO-8859-1 the charset for digest authentication in 2.0 and another that adds params for configuring HTTP element and credential charset. Please take a look and let me know what you think. Mike - 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: To test this problem I'm using Apache HTTPD 2.0.40. I tried using Tomcat, but was unable to get it working with Digest. It seems that Apache uses UTF-8 to encode the user name and password. Not only does this mean that UTF-8 must be used when calculating the digest, it also means that the Authorization header must be sent as UTF-8. This is due to the fact that the digest username is sent as a header parameter. When using Basic authentication I was unable to use non-ASCII characters with Apache. It would be interesting to see which encoding is used by the Mozilla and IE. Have you checked that too, Mike? - 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
Mozilla uses UTF-8. I also tried with Safari and Mac IE. Neither of them work against the Apache digest authentication, so I cannot tell what they are using. Mike On Nov 24, 2003, at 4:31 AM, Ortwin Glück wrote: [EMAIL PROTECTED] wrote: To test this problem I'm using Apache HTTPD 2.0.40. I tried using Tomcat, but was unable to get it working with Digest. It seems that Apache uses UTF-8 to encode the user name and password. Not only does this mean that UTF-8 must be used when calculating the digest, it also means that the Authorization header must be sent as UTF-8. This is due to the fact that the digest username is sent as a header parameter. When using Basic authentication I was unable to use non-ASCII characters with Apache. It would be interesting to see which encoding is used by the Mozilla and IE. Have you checked that too, Mike? - 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 24671] - Basic Authentification fails with non-ASCII username/password characters
Michael Becke wrote: Mozilla uses UTF-8. I also tried with Safari and Mac IE. Neither of them work against the Apache digest authentication, so I cannot tell what they are using. Mike I just tried with IE 5.5 on Windows and it returns a strange error message (DNS error, which seems like a catch-all for IE) when even encountering digest auth Mozilla just works fine on the same location. However I could not get it to work with non-ASCII usernames. Odi - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 21:40 --- Well, I've spent a lot more time working on this than I would have thought. It seems there may not be a good, universal solution for this problem. Originally I was thinking that we should just switch over to 8859-1 for digest user names and passwords, like we did for basic authentication. After some more researching and testing it seems that this may not be the correct answer. To test this problem I'm using Apache HTTPD 2.0.40. I tried using Tomcat, but was unable to get it working with Digest. It seems that Apache uses UTF-8 to encode the user name and password. Not only does this mean that UTF-8 must be used when calculating the digest, it also means that the Authorization header must be sent as UTF-8. This is due to the fact that the digest username is sent as a header parameter. When using Basic authentication I was unable to use non-ASCII characters with Apache. I found the following two threads that discuss the problem with non-ASCII charsets and HTTP authentication, unfortunately neither of them seem to come to a complete conclusion: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998SepDec/0040.html http://lists.w3.org/Archives/Public/ietf-http-wg/2003AprJun/0002.html I will attach shortly two patches that I used to test this problem, one for UTF-8 and the other for ISO-8859-1. Unless we can come up with a better solution for this I suggest that we stick to ASCII for 2.0 and add a configuration item for 2.1 that determines that charset to use for authentication. What does everyone think? Mike - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 21:50 --- Created an attachment (id=9242) 8859-1 patch - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 21:50 --- Created an attachment (id=9243) UTF-8 patch - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 21:51 --- Created an attachment (id=9244) Simple test class - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 22:42 --- Mike, I do not like the idea of using non-ASCII characters in 'Authorization' headers, at least in those headers only. Probably we should introduce an option to encode HTTP headers using ISO-8859-1 or UTF-8 to accommodate for all sorts of not-so-compliant behaviors with regards to HTTP header content. This said, I do think that digest scheme user names are not meant to have non-ASCII content, as it would constitute a gross violation of the RFC2616. But I do admit that it can be subject to different interpretations I am +1 to stick to ASCII for the 2.0 release, as least for user names Oleg - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 23:19 --- Oleg, I agree, setting a different charset for a single header is not good. If we were to implement this for real I think we would want a config option for all the headers. The only question then would be if we want to allow another different charset for for the username/password before they are digested/base64 encoded. Though using charsets other than ASCII for user names/password does not jibe well with RFC 2616/17, there is no standard solution for handling these cases. Is seems that different vendors have made different choices for supporting non-ASCII values in credentials. To be a good client I think we need to be flexible in how we support authentication. As for 2.0 do you think we should roll back the support for 8859-1 values in basic authentication? Mike - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 23:31 --- The only question then would be if we want to allow another different charset for for the username/password before they are digested/base64 encoded. I think that should go without saying As for 2.0 do you think we should roll back the support for 8859-1 values in basic authentication? What if we used ISO-8859-1 to encode the password in the digest scheme instead? - 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
On Nov 22, 2003, at 6:31 PM, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 23:31 --- The only question then would be if we want to allow another different charset for for the username/password before they are digested/base64 encoded. I think that should go without saying Yes, the only caveat being that the digest username and the headers will need to be in the same encoding. As for 2.0 do you think we should roll back the support for 8859-1 values in basic authentication? What if we used ISO-8859-1 to encode the password in the digest scheme instead? We can support 8859-1 in the password, just not the username, since that would require sending the headers as 8859-1. I guess we might as well have partial support for non-ASCII chars now and we can build upon it in 2.1. Mike - 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|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 21:38 --- Mike, I set up Apache http server 2.0.48 on Win2K (Prof), enabled digest authentication for a directory, and created an user account with a password containing German umlauts. I hit the URL with Mozilla Firebird 0.7 and attempted to authenticate using the password. It did not work. I may know why. If the RFC 2617 is to be strictly adhered to, only ASCII characters in passwords should be allowed for basic digest authentication RFC 2617, Section 2: Basic Authentication Scheme quote basic-credentials = base64-user-pass base64-user-pass = base64 [4] encoding of user-pass, except not limited to 76 char/line user-pass = userid : password userid = *TEXT excluding : password= *TEXT /quote RFC 822 defines TEXT as quote text= any CHAR, including bare; = atoms, specials, CR bare LF, but NOT ; comments and including CRLF ; quoted-strings are ; NOT recognized. /quote RFC 822 defines TEXT as quote ; ( Octal, Decimal.) CHAR= any ASCII character; ( 0-177, 0.-127.) /quote However, I do think that in this instance the spec is too restrictive and we should be using ISO-8859-1 instead of ASCII. So, I reopen the bug. Sorry for having closed it prematurely - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 00:19 --- Oleg, No worries about closing the bug. I was a little slow in getting to it. I agree. I think we should be using 8859-1 instead of ASCII. The following section from RFC 2616 seems to imply that TEXT should be 8859-1, though it is a little vague: The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047draft [14]. TEXT := any OCTET except CTLs, but including LWS Either way I think digest needs to be fixed. I will create a patch. Mike - 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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 03:23 --- I left it open to remind me to investigate this problem with digest authentication. I haven't been able to test it out, but I believe we have the same problem with digest. Has anyone tried digest with non-ASCII characters? Mike - 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]
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]
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 --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 03:03 --- Created an attachment (id=9084) Patch 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
