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: Leo Liu <sdl.web <at> gmail.com>
Cc: 23750 <at> debbugs.gnu.org
Subject: bug#23750: 25.0.95; bug in url-retrieve or json.el
Date: Mon, 20 Jun 2016 17:39:04 +0300

> From: Leo Liu <sdl.web <at> gmail.com>
> Date: Mon, 20 Jun 2016 08:15:26 +0800
> 
> > 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.
> 
> As Dmitry mentioned earlier json-encode in 25.1 produces multibyte
> strings and makes it easier to hit this bug when consuming JSON API's.
> There are three parties that are suspicious: 1) JSON API server 2)
> JSON.el 3) URL. It took me a while to realise it's URL's fault IOW the
> bug isn't easy to debug. This is somewhat related to changes brought in
> by 25.1.

I understand that url-http expects unibyte strings.  So my suggestion
is to test that, and signal an error if the requirement is violated,
with an error message text that could be understood by users and
developers.

Alternatively, we could encode multibyte strings in UTF-8, if we want
to attempt to silently cope with such strings.

In any case, using string-*-unibyte functions for that is not needed,
and I'm quite sure their use in this case is a left-over from an era
long gone.

Previous Next

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