From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#24117: 25.1; url-http-create-request: Multibyte text in HTTP request Date: Wed, 3 Aug 2016 05:39:31 +0300 Message-ID: <27168f12-32d2-cb38-45c0-27d3339c75aa@yandex.ru> References: <83d1ltq3p6.fsf@gnu.org> <83popsocg8.fsf@gnu.org> <7fb3540a-7b74-68cf-2c63-66474de26640@yandex.ru> <83mvkvmbv2.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1470192049 10621 195.159.176.226 (3 Aug 2016 02:40:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2016 02:40:49 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0 Cc: stakemorii@gmail.com, Lars Magne Ingebrigtsen , 24117@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 03 04:40:45 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1bUm6t-0002Kg-Vj for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Aug 2016 04:40:44 +0200 Original-Received: from localhost ([::1]:59830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUm6q-0003dP-K6 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Aug 2016 22:40:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUm6K-0003HH-Rr for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2016 22:40:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUm6E-0008RK-Tl for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2016 22:40:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUm6E-0008RC-Po for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2016 22:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bUm6E-00083E-Du for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2016 22:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Aug 2016 02:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24117-submit@debbugs.gnu.org id=B24117.147019198130908 (code B ref 24117); Wed, 03 Aug 2016 02:40:02 +0000 Original-Received: (at 24117) by debbugs.gnu.org; 3 Aug 2016 02:39:41 +0000 Original-Received: from localhost ([127.0.0.1]:53977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUm5t-00082R-6W for submit@debbugs.gnu.org; Tue, 02 Aug 2016 22:39:41 -0400 Original-Received: from mail-lf0-f52.google.com ([209.85.215.52]:33257) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUm5r-00082A-RM for 24117@debbugs.gnu.org; Tue, 02 Aug 2016 22:39:40 -0400 Original-Received: by mail-lf0-f52.google.com with SMTP id b199so151457970lfe.0 for <24117@debbugs.gnu.org>; Tue, 02 Aug 2016 19:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=62gA331l84B1xJfL7amyvcS+5iRrmJgRk0GI73tCHcg=; b=v35LRPUy0ogFmjZYvkjnhqlZZSJNT5vv/GqgnH5w9SA2gMJZF3lgePdnByowycLbzE TOr6EQux3AmMV2/ZRBBThw71nNX8U9eefkzHlVLxUngrVExR5R44+KP5lSlj6pfS7b9i 8Lz+v8FsCGuvSvKuW8xerrL6Fs6Y5EW/x340x7SEU92Mgz2PzhdWo+zXIvvXN7gxvKx4 QiaKPm782xKaxuOylhQBxEJfKT0g3YiS4aIznWcuvRdqm9fNDDc1wZ9NbmbujWGG10Ww EsZKoSpTHMm+mS2itYMOW9WyKLxIjxS9CM3C2TQyJoMSBHULs/yJJmIk0WO/a8ers7Yw dsPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=62gA331l84B1xJfL7amyvcS+5iRrmJgRk0GI73tCHcg=; b=G+mhaYK8B7Dk76wrDuhgDIHl95QkfGCg0GluApuGA8jhsy1Ny6sfKgQQ/bTYYeqbM3 0kzlFCv8Wwhmorwwp8B/RqZxZcjPXmGe6Z34P3h7/rnL0K9MjygL5IhLG/9XD6uAjlwi /ip9+XMpIX309bFtvbepz2qK4m6bTqS/u6YC78H+cXgtrlyYn8hfWtsECYDWoVYsQVQ8 YmkALxEwxZbwhthPDYg7b025bEJCyzDMjngtvTYhR9g786f1p6Uy+ZMTLAC2cgxX9HGL hY8OKXt9PO0rYQXuLFFbUy5RKiVV3opYxcBH2fl+JQ6/nGSBPUBukT0NTGj5A10jL0WI ul9Q== X-Gm-Message-State: AEkooutCB7yujEfaiIQmpeTe85ZWkeSfKXBfvvLMPWZhkPDdx5w76GPq729c22/AHbD67A== X-Received: by 10.25.41.142 with SMTP id p136mr21750270lfp.32.1470191973718; Tue, 02 Aug 2016 19:39:33 -0700 (PDT) Original-Received: from [192.168.1.190] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id y200sm997952lfd.12.2016.08.02.19.39.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 19:39:32 -0700 (PDT) In-Reply-To: <83mvkvmbv2.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:121796 Archived-At: On 08/02/2016 06:25 PM, Eli Zaretskii wrote: > How about making the temporary buffer parsed by url-generic-parse-url > a unibyte buffer? Does that fix the problem? It does fix anaconda-mode, yes. > AFAIU, RFC 3986 doesn't > allow non-ASCII characters, so we should be okay handling that in a > unibyte buffer, right? I don't really know. RFC 3986 or not, I suppose in practice the url could be quoted before or after it's parsed. And url-parse-tests.el doesn't specify this case. Lars, what do you think? > I mean something like this: > > (with-temp-buffer > ;; Don't let those temp-buffer modifications accidentally > ;; deactivate the mark of the current-buffer. > (let ((deactivate-mark nil)) > (set-syntax-table url-parse-syntax-table) > (erase-buffer) > (set-buffer-multibyte nil) ;; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > (insert url) > (goto-char (point-min)) > ... Heh, that's exactly where I added the line, without looking at your code. > As for other possible problems like that, are there any that could be > expected already? If so, we could try fixing them now. Nothing else jumps out so far. The function depends on quite a few global variables. To be really certain, we'd have to trace how all of them are created, and for all that are not directly bound by the user, the chains of calls that produce them. > Alternatively, we could just wait for them to come up; I'm worried about having a problem crop up in some significant use case after we release 25.1. That doesn't feel very probable, but still. > after all, > catching those was the main rationale for introducing the length test, > right? The most important part was to make sure that the length of the body in bytes is equal to the value of the Content-Length header (the difference caused actual problems). But then we decided to make the check wider and test that the whole request string is unibyte-ish. Which made sense, but seems to be working out less well than we expected.