|
From: | Dmitry Gutov |
Subject: | bug#24117: 25.1; url-http-create-request: Multibyte text in HTTP request |
Date: | Tue, 9 Aug 2016 05:13:04 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0 |
On 08/08/2016 11:36 PM, Lars Ingebrigtsen wrote:
(url-encode-url "http://góogle.com/fóo") => "http://góogle.com/f%C3%B3o"That is true in master, but not in emacs-25, AFAICS. (Is that related to your work on punycode?)Might be; I can't recall, though.
Here's another question: why does url-encode-url pass the argument through encode-coding-string before passing it to url-generic-parse-url, if the latter is expected to be able to deal with non-ASCII characters?
The only recent change in that function is your commit 8b61c22e dated last December, which very much looks like a band-aid in this context.
On emacs-25, it returns "http://g%C3%B3ogle.com/f%C3%B3o".Which is, of course, completely wrong.
I see.Since you're better versed in this area than me, can you propose a specific fix for the currently discussed bug? It is more serious than not being able to use unicode in URLs.
On master, the domain part, which is untouched by url-encode-url, is converted to an ASCII unibyte string with puny-encode-domain, inside url-http-create-request. But real-fname remains a multibyte string, triggering the problem anyway.
[Prev in Thread] | Current Thread | [Next in Thread] |