From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bug#23750: 25.0.95; bug in url-retrieve or json.el Date: Wed, 30 Nov 2016 20:44:51 +0200 Message-ID: <83r35sq02k.fsf@gnu.org> References: <6d0c8c2e-8428-2fdb-0d6e-899f7b9d7ffd@nifty.com> <8053af81-80e1-a24a-f649-8ffc86963ed5@nifty.com> <0cc7fab4-9a2c-6a8d-def7-36bd50317ca3@yandex.ru> <7f9a799f-de88-fd78-0cdc-dac0928f1503@nifty.com> <308bb78f-8be3-092d-d877-e129d340242b@nifty.com> <4dc615e7-ec73-60a5-426e-0d6986f15d76@yandex.ru> <0cb406fb-ffc4-a4ad-557a-2cacc99b8e75@nifty.com> <86ccb4af-5719-c017-26bb-fc06b4c904d2@yandex.ru> <83r35uxkr5.fsf@gnu.org> <4e12d4ad-cd6b-3087-5d7c-449d4c1886e2@yandex.ru> <83lgw1q9uu.fsf@gnu.org> <83eg1tq8is.fsf@gnu.org> <787e5206-53e0-752f-a339-4608d2f7ad39@yandex.ru> <8360n5q6j4.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480531527 20276 195.159.176.226 (30 Nov 2016 18:45:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2016 18:45:27 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org, kentaro.nakazawa@nifty.com, dgutov@yandex.ru To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 30 19:45:23 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cC9sf-0004Od-JF for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 19:45:21 +0100 Original-Received: from localhost ([::1]:45726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cC9sj-0006CJ-8G for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 13:45:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cC9sS-00061e-2N for emacs-devel@gnu.org; Wed, 30 Nov 2016 13:45:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cC9sO-0002Jx-7F for emacs-devel@gnu.org; Wed, 30 Nov 2016 13:45:08 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cC9sO-0002Jq-3h; Wed, 30 Nov 2016 13:45:04 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2611 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cC9sL-000328-3w; Wed, 30 Nov 2016 13:45:03 -0500 In-reply-to: (message from Philipp Stephani on Wed, 30 Nov 2016 18:23:14 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209825 Archived-At: > From: Philipp Stephani > Date: Wed, 30 Nov 2016 18:23:14 +0000 > Cc: dgutov@yandex.ru, kentaro.nakazawa@nifty.com, emacs-devel@gnu.org > > > Yes, this is not a json.el problem at all. It does the correct thing, > > and shouldn't be changed. > > ??? Why should any code care whether a pure-ASCII string is marked as > unibyte or as multibyte? Both are "correct". > > I guess the problem is that process-send-string cares. If it didn't, we wouldn't have the problem. I don't think I follow. The error we are talking about is signaled from url-http-create-request, not from process-send-string. > For URL, we'd need functions like > (byte-array-length s) = (length (string-to-unibyte s)) Why do you need this? string-to-unibyte is well-defined only for unibyte or ASCII strings (if we forget the raw bytes for a moment), so length will do. > (process-send-bytes s) = (process-send-string (string-to-unibyte s)) Why is this needed? process-send-string already encodes its argument, which produces a unibyte string. > (conceptually; process-send-string also does EOL conversion, which should never be done for HTTP > bodies.) I don't understand why. There are protocols that require CR-LF, no?