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

Previous Next

Full log

Message #29 received at 23750 <at> debbugs.gnu.org (full text, mbox):

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

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.

Previous Next

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