From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: bug#23750: 25.0.95; bug in url-retrieve or json.el Date: Wed, 28 Dec 2016 18:09:52 +0000 Message-ID: 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> <83r35sq02k.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b86cf3eb2be430544bbe0b4 X-Trace: blaine.gmane.org 1482948631 15278 195.159.176.226 (28 Dec 2016 18:10:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Dec 2016 18:10:31 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org, kentaro.nakazawa@nifty.com, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 28 19:10:25 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 1cMIg3-00026r-LR for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 19:10:15 +0100 Original-Received: from localhost ([::1]:60382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMIg8-0004Wp-Gt for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 13:10:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMIfy-0004WH-Ln for emacs-devel@gnu.org; Wed, 28 Dec 2016 13:10:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMIfx-00016W-8B for emacs-devel@gnu.org; Wed, 28 Dec 2016 13:10:10 -0500 Original-Received: from mail-wj0-x235.google.com ([2a00:1450:400c:c01::235]:36343) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMIfr-00011L-Vp; Wed, 28 Dec 2016 13:10:04 -0500 Original-Received: by mail-wj0-x235.google.com with SMTP id c11so137419981wjx.3; Wed, 28 Dec 2016 10:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vh1AunJKfa5Q5aCra2K6RvxmXfut9Qzmdiduyi0cHn8=; b=ZsfPtEVS7if+Ed7Lp6lRWZdXUvUEXhYT33mdgElyn+Sf1mAGQSU5m8KkUOWPVGwdku vCmIfjVKz0vRkh6E6t0xGwtDK3S7bzw4K+0lOo7AirrVFkZXuGtvQYSKefadbCpx69mN K068qa8mv6azeDt2DkzEdDYvSdMNlWhqLw7mEoaTPxz1Bv6fE7yusg2Ujg5BoIkpB4TZ 3lXS9HmDcQZYScv1eFtrggNS6QC7YmWz/b1JCLi7VKcDzMW+i3fmzOczrYKdjYS3IXtc /zSm9ujIfVALtzdrvpwYG9VH6MeNYoRybnm55+p8qDOItqgzGqtUNy1L5dhbm5DMcdM+ mCDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vh1AunJKfa5Q5aCra2K6RvxmXfut9Qzmdiduyi0cHn8=; b=WNjzK8yHn2lf9S7fQalzWOxB7I4amY/OIxshNyayChy7WuwNDiHVOIPjBK5vPVhh8Q 1w2cmqLU+3bk3bN+u5KOF6aMn1PUUWooL9m2laujkKwIjy7DLIcv6WO87ORxrrb3K1pv 8U3cvE5qDbrp9+2iE3ttyI5VXZw7IfLheLsQGgjiNNTLBZhhuXaB9lkZnn8DhnrRMn3l dtUBRJOP0r2JoGJnqmUgg84ZL7Qsr3EHNv4Q72ZUdnN5GJ0g5Tuqot1HUC17bNPi2hKC 0WozQd6uFBrvvpOrtuWIvsGsjajh4sXLDXBjnzVAq7xjIVZj8jdPn2aNQjS1r5kFPTYn opFw== X-Gm-Message-State: AIkVDXLyBKV59v2HNIFN+prvMToS/Fox5yjW1PMZFIic1YjTyFaETpghPskmqBo5qyCXQEtJW+nN0OOLEBmN4w== X-Received: by 10.194.58.7 with SMTP id m7mr20990544wjq.73.1482948602935; Wed, 28 Dec 2016 10:10:02 -0800 (PST) In-Reply-To: <83r35sq02k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c01::235 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:210916 Archived-At: --047d7b86cf3eb2be430544bbe0b4 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Mi., 30. Nov. 2016 um 19:45 Uhr: > > 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. > Yes, but url-http-create-request only cares about unibyte strings because the request it creates is passed to process-send-string, which special-cases unibyte strings. > > > 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. > We need it because we have to send the byte length in a header. We can't just use (length s) because it would silently give a wrong result. > > > (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. > We can't give a multibyte string to process-send-string, because we have to pass the length in bytes in a header first. Therefore we have to encode any string before passing it to process-send-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? > > Yes, but HTTP request/response bodies should just be byte arrays and no conversion whatsoever should happen. After all, the body could be a binary data format. --047d7b86cf3eb2be430544bbe0b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Mi., 30. Nov. 2016 um 19:45=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 30 Nov 2016 18:23:14 +0000
> Cc: dgutov@yandex.ru, kentaro.nakazawa@nifty.com, em= acs-devel@gnu.org
>
>=C2=A0 > Yes, this is not a json.el problem at all. It does the corr= ect thing,
>=C2=A0 > and shouldn't be changed.
>
>=C2=A0 ??? Why should any code care whether a pure-ASCII string is mark= ed as
>=C2=A0 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.=C2=A0 The error we are talking about is signale= d
from url-http-create-request, not from process-send-string.

Yes, but url-http-create-request o= nly cares about unibyte strings because the request it creates is passed to= process-send-string, which special-cases unibyte strings.
=C2=A0=

> For URL, we'd need functions like
> (byte-array-length s) =3D (length (string-to-unibyte s))

Why do you need this?=C2=A0 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.

We need it bec= ause we have to send the byte length in a header. We can't just use (le= ngth s) because it would silently give a wrong result.
=C2=A0

> (process-send-bytes s) =3D (process-send-string (string-to-unibyte s))=

Why is this needed?=C2=A0 process-send-string already encodes its argument,=
which produces a unibyte string.
<= br>
We can't give a multibyte string to process-send-string, = because we have to pass the length in bytes in a header first. Therefore we= have to encode any string before passing it to process-send-string.
<= div>=C2=A0

> (conceptually; process-send-string also does EOL conversion, which sho= uld never be done for HTTP
> bodies.)

I don't understand why.=C2=A0 There are protocols that require CR-LF, n= o?


Yes, but HTTP requ= est/response bodies should just be byte arrays and no conversion whatsoever= should happen. After all, the body could be a binary data format.=C2=A0
--047d7b86cf3eb2be430544bbe0b4--