bug#24117: 25.1; url-http-create-request: Multibyte text in HTTP request

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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?

I don't know.  I don't think `url-encode-url' has ever really worked in
any sensible way in the presence of non-ASCII.

> 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.

It's debatable what that function should return in the presence of
non-ASCII domain names, but it's a debatable function all around.

> 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.

I didn't understand the original bug report and there was no simple
recipe to reproduce the bug.  Why changing url-generic-parse-url was
proposed as a solution is even less unclear.  Perhaps you could write a
test case and summarise what you think the problem is?

> 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.

The domain is encoded according to IDNA, which is an ASCII string, yes.
(Whether the function returns a unibyte string or not I can't recall.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no