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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 04 Aug 2016 20:02:55 +0300

> Cc: [email-masked], [email-masked],
>  Lars Magne Ingebrigtsen <[email-masked]>
> From: Dmitry Gutov <[email-masked]>
> Date: Wed, 3 Aug 2016 05:39:31 +0300
> 
> On 08/02/2016 06:25 PM, Eli Zaretskii wrote:
> 
> > How about making the temporary buffer parsed by url-generic-parse-url
> > a unibyte buffer?  Does that fix the problem?
> 
> It does fix anaconda-mode, yes.

Hmm, but url-generic-parse-url is called from gazillion other places,
so maybe this is not safe.

> > AFAIU, RFC 3986 doesn't
> > allow non-ASCII characters, so we should be okay handling that in a
> > unibyte buffer, right?
> 
> I don't really know. RFC 3986 or not, I suppose in practice the url 
> could be quoted before or after it's parsed. And url-parse-tests.el 
> doesn't specify this case.

No, I meant that since RFC 3986 doesn't allow non-ASCII characters,
and url-generic-parse-url doesn't do anything about that, it is either
already broken for non-ASCII characters, or already copes with them.
So we don't need to worry about that.

However, a safer change would be to do something like this:

   (or (not (multibyte-string-p url-http-target-url))
       (setq url-http-target-url
             (decode-coding-string url-http-target-url 'utf-8)))

in url-http-create-request.  Can you try this?

Thanks.