From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniele Nicolodi Newsgroups: gmane.emacs.bugs Subject: bug#42382: 26.3; url-http handling of Location redirection headers containing whitespace Date: Fri, 17 Jul 2020 09:47:45 -0600 Message-ID: <8d46b964-9cbc-7c44-3aac-5e512594748c@grinta.net> References: <875e714c-28f3-7a4e-7a9e-0f4ce640e336@grinta.net> <4225b17a-c74f-64ed-4270-3689979de066@grinta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34549"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: 42382@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 17 17:56:51 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jwSjB-0008rB-G5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Jul 2020 17:56:49 +0200 Original-Received: from localhost ([::1]:60456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwSjA-0001dO-Hy for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Jul 2020 11:56:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwSiQ-0001UN-HJ for bug-gnu-emacs@gnu.org; Fri, 17 Jul 2020 11:56:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46379) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jwSiQ-0004E5-7m for bug-gnu-emacs@gnu.org; Fri, 17 Jul 2020 11:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jwSiQ-0004qV-72 for bug-gnu-emacs@gnu.org; Fri, 17 Jul 2020 11:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniele Nicolodi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Jul 2020 15:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42382 X-GNU-PR-Package: emacs Original-Received: via spool by 42382-submit@debbugs.gnu.org id=B42382.159500131818546 (code B ref 42382); Fri, 17 Jul 2020 15:56:02 +0000 Original-Received: (at 42382) by debbugs.gnu.org; 17 Jul 2020 15:55:18 +0000 Original-Received: from localhost ([127.0.0.1]:57920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwShh-0004p3-D7 for submit@debbugs.gnu.org; Fri, 17 Jul 2020 11:55:18 -0400 Original-Received: from grinta.net ([109.74.203.128]:47536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwSaX-0004du-EZ for 42382@debbugs.gnu.org; Fri, 17 Jul 2020 11:47:54 -0400 Original-Received: from black.local (c-73-229-170-236.hsd1.co.comcast.net [73.229.170.236]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id 58E1FE0970; Fri, 17 Jul 2020 15:47:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1595000871; bh=t3OMqj+mWiy3zhaCnSxNjD9wGFAWtBcpzsHs3DranyA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MRJArlRWkA4OgsspzZG8roUJ6GNNPweFNyN7JHZSdQFcDIUD37CHiQCPPqFLhHjWu Q4cUtlt4mGPt42ccllaCGAb90ZaJOfym4ZiyBLzvdtk0IbaROeI7p5fC3KWQ2szAi5 PMzn8PyAFUT/cYBbx6Sa5pCHoOOomflvr68G49rkR6he8QQVFzDmhBnlvRKAa12h9A pkzPDp3N1MQ18xTcbdct1bFEguOEfO84G3nmFq9/bAxDu+15CwBj3TP4dsIidzArFg ziKf/moA9yciPy+O/e8Dfq3fasISx/iNA0kQgUSbcZBW84ZVUV+EnC+7rxxkec5JM8 nGr76kPwW6SsQ== In-Reply-To: Content-Language: en-US X-Mailman-Approved-At: Fri, 17 Jul 2020 11:55:15 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:183156 Archived-At: On 16/07/2020 11:10, Robert Pluim wrote: > You stated that angle quotes were invalid, and proposed to remove the > support for their presence. I was merely pointing out that spaces are > equally invalid, and you propose to accomodate them. If one, why not > the other? Technically, I am not proposing to accommodate anything. I am proposing to use the Location header as returned by the server, without trying to guess what the server really meant. If you want to look at it in another way, I am proposing to modify url-http to follow what all other HTTP client implementations do. The standard does not specify what to do in case of malformed header values, thus adopting the most common approach allows for greater interoperability. The fact that this is also the simplest thing to do is also very attractive. Finally, as Lars points out, angle bracket enclosed URIs in Location headers have not been seen anywhere. Thus stripping them out is fixing an imaginary problem, and we can come up with an infinite list of imaginary problems that need to be "fixed". Non fixing any of them is the reasonable thing to do. > Daniele> Why is percent-encoding better? The URI-reference value should not be > Daniele> interpreted in any way, simply passed along. Again, all other HTTP > Daniele> clients I looked at do not do this, or other manipulation of the header. > > Because then it become a valid URI, and other parts of emacs that > donʼt know how to treat literal spaces in a URI wonʼt break. But Iʼll > agree that itʼs conjecture on my part. The code I would like to fix does not expose the values of the headers in any way, and it works just fine with non-escaped spaces, thus there is no need to fix the percent-encoding. Trying to fix the value of the URI-location value is a very slippery slope. We can fix non-escaped spaces, but what about other non-escaped characters? Should we escape them as well or leave them alone? If we leave them alone, there is little value in escaping spaces (the invariable "correctly percent-escaped URIs are returned, SOMETIMES" is weaker than "the content of the Location header is return as is, ALWAYS"). If we try to fix the escaping, how can we know that when we get a URI containing a % character, this is a valid escape sequence an not a literal % that needs to be escaped? We are back to the "correct answer most of the times", which is not very helpful. Thank you. Cheers, Dan