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

[Eli Zaretskii]

> Cc: 23750@debbugs.gnu.org, monnier@IRO.UMontreal.CA, sdl.web@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 19 Jun 2016 21:36:25 +0300
> 
> 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.

So this is not a bug in Emacs, but a diagnostic facility to let bugs
in applications be discovered?

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

If this is what you need, why not simply test the payload for being a
unibyte string?  There a function, multibyte-string-p, for that.