From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 080C61F461 for ; Sat, 18 May 2019 22:58:39 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 1B7A7120F30; Sun, 19 May 2019 07:58:33 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id BFD15120F58 for ; Sun, 19 May 2019 07:58:30 +0900 (JST) Received: by filter0063p3iad2.sendgrid.net with SMTP id filter0063p3iad2-8244-5CE08E16-26 2019-05-18 22:58:30.986969678 +0000 UTC m=+260394.640483699 Received: from herokuapp.com (unknown [54.167.227.248]) by ismtpd0026p1iad2.sendgrid.net (SG) with ESMTP id QaynOI4kSPyqCQyB4IHDRQ for ; Sat, 18 May 2019 22:58:30.980 +0000 (UTC) Date: Sat, 18 May 2019 22:58:31 +0000 (UTC) From: matthew@kerwin.net.au Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 68202 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15861 X-Redmine-Issue-Author: deivid X-Redmine-Sender: phluid61 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?dc6bl8=2FRfjZl6IUFmz6hrXGqzg+6U4v9dH0u7=2FcQTE=2FcTYodjiEyjW1Lq9gEi7?= =?us-ascii?Q?MJs+JiW24jCn7HCLLerk4bX4zNCJXMfYDftcfn1?= =?us-ascii?Q?XbOjSx3OY7QYg6U74p9hzbAFUCCrwvzx=2FSxKdTB?= =?us-ascii?Q?6wq0nDOpu+uRO+WvgRQC2vnrc6lzXq2NmegWlrx?= =?us-ascii?Q?9mxI9d5ZNkqazlk62zje8gmSW50h5P2MWQg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92718 Subject: [ruby-core:92718] [Ruby trunk Feature#15861] Correctly parse `file:c:/path/to/file` URIs X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15861 has been updated by phluid61 (Matthew Kerwin). jeremyevans0 (Jeremy Evans) wrote: > Looking at RFC 8089, Appendix E (`Nonstandard Syntax Variations`) states: = > = > ``` > These variations may be encountered by existing usages of the file > URI scheme but are not supported by the normative syntax of > Section 2. > = > This appendix is not normative. > ``` > = "may be encountered" here is meant to mean that old "poorly formed" URIs ex= ist in the wild, and occasionally we encounter them. For example, if I wer= e to write a Ruby script to update a bunch of historical documentation from= 1997. It can also mean the kind of stuff humans input, which "worked for = me when I did it in Internet Explorer". > > Appendix E.2 says that the following form is already supported: `file:///= c:/path/to/file`. Using that with the URI library: > = > ```ruby > URI.parse("file:///c:/path/to/file").path > =3D> "/c:/path/to/file" > ``` > = In other words, implement a pre-parser that detects E.2-flavoured URIs and = inserts the extra slash. FWIW there's actually a [gem](https://phluid61.gi= thub.io/file-uri/) out there that does essentially this, however since it w= as written and published alongside RFC 8089 it predates the core File URI h= andling. ``` require 'file-uri/win' URI.parse("file:c:/path/to/file").path =3D> "/c:/path/to/file" ``` > I can see where the preceding `/` may present an issue. However, I am no= t sure whether we want to add support for nonstandard syntax variations to = the `file` scheme. It's a pain, but it's a pain we've lived with forever. FWIW, I added a `#t= o_file_path` method in that gem to see if it makes this particular paint po= int any easier. But I don't think this is the major driver, more it's havi= ng to detect and correct those other URIs. All said; if all else fails there's always Addressable. ---------------------------------------- Feature #15861: Correctly parse `file:c:/path/to/file` URIs https://bugs.ruby-lang.org/issues/15861#change-78075 * Author: deivid (David Rodr=EDguez) * Status: Open * Priority: Normal * Assignee: = * Target version: = ---------------------------------------- Recently ruby has getting better at parsing URIs using the "file" scheme, w= ith the addition of "URI::File". Still, some Windows edge cases are not imp= lemented, and it would be nice to have them. For example, while the [addres= sable gem](https://github.com/sporkmonger/addressable) can correct parse "f= ile:c:/path/to/file", the builtin library is not that smart yet: ``` = irb(main):001:0> URI.parse("file:c:/path/to/file").path =3D> nil irb(main):002:0> require 'addressable' =3D> true irb(main):003:0> Addressable::URI.parse("file:c:/path/to/file").path =3D> "c:/path/to/file" ``` I think this would be a matter of implementing https://tools.ietf.org/html/= rfc8089#appendix-E.2, which is not normative but it would be certainly nice= to have. -- = https://bugs.ruby-lang.org/ Unsubscribe: