GNU bug report logs - #23750
25.0.95; bug in url-retrieve or json.el

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 23750 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA, sdl.web <at> gmail.com
Subject: bug#23750: 25.0.95; bug in url-retrieve or json.el
Date: Mon, 20 Jun 2016 05:40:17 +0300

> Cc: 23750 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA, sdl.web <at> gmail.com
> From: Dmitry Gutov <dgutov <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.