bug#23750: 25.0.95; bug in url-retrieve or json.el

[Dmitry Gutov]

On 06/19/2016 09:25 PM, Eli Zaretskii wrote:

> I'd need a very detailed description of the bug, and why this
> particular solution was used.

This particular bug came from this:

"Content-length: " (number-to-string (length url-http-data))

Which gives wrong value when url-http-data is multibyte (it should be 
length in bytes). So then, the HTTP server on the other side saw the 
wrong body length and truncated the body when reading the request. Or 
something along these lines.

> IME, neither string-to-unibyte not
> string-as-unibyte should ever be used in applications, their use is
> more often than not a sign of some basic misunderstanding of text
> encoding.  For starters, how come 8-bit bytes wind up in that
> function, and what do they stand for?

Some 8-byte encoding of the HTTP request body.

Anyway, yes, the hope is that the programmer uses something like 
encode-coding-string to produce that value (and picks the encoding, and 
indicates it in the appropriate HTTP header). Then string-to-unibyte 
will simply be a no-op. But we need to catch the case when they don't, 
and this seems to be the easiest way to do this.