DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38588>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38588 ------- Additional Comments From [EMAIL PROTECTED] 2006-02-09 13:00 ------- Re: "What the docs want to say is merely that it is not possible to URI-encode non-ASCII character in an unambigous way." This I agree upon, however, unless I use HttpClient as a general purpose enduser operated -browser-, which I hardly think is the most common use case, I will known which servers I talk to, and can adjust my use of HttpClient accordingly. Many use-cases for HttpClient will even be such that the user have control over both endpoints. In these scenarioes there is actually defined and specified a consistent way for how to send full unicode over URLs. I therefore disagree upon the strongish wording in the doc - as most new servers (notably both of Apache's, I believe?) will employ this UTF-8 style assumption. However, before checking this up better before submitting this ER, I really thought that it was common for newer browsers to encode the URL parameters with the same encoding as it uses for the body-part. And that this again typically would be selected by which encoding the server sent as its response (the browser would thus in effect adjusts to the server, where the server picks one of the browsers accepted encodings). But in the specs I mentioned, it basically states that "use UTF-8 always". -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
