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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 10 Aug 2016 17:35:28 +0300

> Cc: [email-masked], [email-masked], [email-masked]
> From: Dmitry Gutov <[email-masked]>
> Date: Wed, 10 Aug 2016 10:12:40 +0300
> 
> On 08/09/2016 05:50 PM, Eli Zaretskii wrote:
> 
> >> You can't encode it properly without parsing it first.
> >
> > You don't say what you meant by "encode properly".  It's just a
> > string, and there are ways to make a string unibyte without any
> > parsing.
> 
> Different parts of an URL are supposed to be encoded in different ways.
> 
> For instance,
> 
>    http://банки.рф/фыва/
> 
> turns into
> 
>    http://xn--80abwho.xn--p1ai/%D1%84%D1%8B%D0%B2%D0%B0/

Are you saying that url-generic-parse-url performs this encoding, and
that using a unibyte buffer causes that to fail?

> So I think the encoding of the URL parts should be performed inside 
> url-http-create-request.

Fine with me, but when I suggested that, you didn't like the
suggestion.  If you changed your mind, let's do that.

> On the master branch, host is passed through IDNA encoding, but
> real-fname is untouched. On emacs-25, I think we should convert both
> to unibyte.

Not sure I understand why there should be a difference between the two
branches.  Encoding an ASCII string doesn't do any harm.

> Not sure encode-coding-string is the way to go (why would we assume 
> UTF-8?).

Because using UTF-8 doesn't lose anything, you basically get the same
byte stream as stored internally (because 8-bit bytes are not supposed
to happen in URLs).

> (Why doesn't (encode-coding-string "aaaa" 'ascii) work?)

It's 'us-ascii, not 'ascii.