From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] url: Wrap cookie headers in url-http--encode-string. Date: Fri, 9 Sep 2016 16:56:54 +0200 Message-ID: <86sht9qfyh.fsf@realize.ch> References: <20160907153014.15752-1-toke@toke.dk> <87inu7k5z4.fsf@toke.dk> <83bmzzaawr.fsf@gnu.org> <877fank1oc.fsf@toke.dk> <87inu6iim8.fsf@toke.dk> <2563921f-d20d-753b-09eb-c8671bc5b6d6@yandex.ru> <87a8fiidso.fsf@toke.dk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1473433085 25400 195.159.176.226 (9 Sep 2016 14:58:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2016 14:58:05 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) Cc: Eli Zaretskii , emacs-devel@gnu.org, monnier@iro.umontreal.ca, Dmitry Gutov To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 09 16:57:57 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 1biNFZ-0005PQ-VT for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2016 16:57:54 +0200 Original-Received: from localhost ([::1]:58365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biNFX-0001iB-N2 for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2016 10:57:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biNFL-0001f5-0w for emacs-devel@gnu.org; Fri, 09 Sep 2016 10:57:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biNFF-0005Io-3g for emacs-devel@gnu.org; Fri, 09 Sep 2016 10:57:39 -0400 Original-Received: from clientmail.realize.ch ([46.140.89.53]:3522) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1biNFA-0005HP-1g; Fri, 09 Sep 2016 10:57:28 -0400 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Fri, 9 Sep 2016 16:57:16 +0200 Original-Received: from MYNGB (192.168.66.65) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Fri, 9 Sep 2016 16:56:54 +0200 In-Reply-To: <87a8fiidso.fsf@toke.dk> ("Toke \=\?iso-8859-1\?Q\?H\=F8iland-J\=F8\?\= \=\?iso-8859-1\?Q\?rgensen\=22's\?\= message of "Thu, 08 Sep 2016 17:58:31 +0200") X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] X-Received-From: 46.140.89.53 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:207310 Archived-At: Toke H=F8iland-J=F8rgensen writes: > Dmitry Gutov writes: >> >> Could you post the full recipe? > > (url-retrieve-synchronously "http://google.se") ; sets a cookie > (let* ((url-request-data (encode-coding-string "=E6=F8=E5" 'utf-8))) > (url-retrieve-synchronously "http://google.se")) ; crashes I was able to reproduce it but am a bit confused, since it doesn't signal an error when message-body "=E6=F8=E5" is replaced by "abc", while reusing the same cookie. I tried to track it down with the following example. `cookie-val' is the value of the cookie-string: (string-bytes cookie-val) =3D> 131 (string-bytes (encode-coding-string "=E6=F8=E5" 'utf-8)) =3D> 6 (string-bytes (concat (encode-coding-string "=E6=F8=E5" 'utf-8) cookie-val)) =3D> 143 ' why? (string-bytes (concat (string-as-unibyte "abc") ans-cookie-val)) =3D> 134 Why does concat behave that strangely? What am I missing here? Is the behavior of concatenating a unibyte and a multibyte string simply undefined? But if so, shouldn't that be mentioned in the docstring? Or is it a general rule that has to be followed, to not mix uni-/multibyte in any function? Please excuse me if that seems to be a silly question to you. I just want to learn and understand how that really works behind the scenes. Thanks for any help.