[swift-evolution] (core library) modern URL types

[Taylor Swift]

So are you saying we need *three* distinct “URI” types for local-absolute,
local-relative, and remote? That’s a lot of API surface to support.

On Tue, Aug 22, 2017 at 12:24 PM, Dave DeLong <delong at apple.com> wrote:

> I completely agree. URL packs a lot of punch, but IMO it’s the wrong
> abstraction for file system paths.
>
> I maintain an app that deals a *lot* with file system paths, and using
> URL has always felt cumbersome, but String is the absolute wrong type to
> use. Lately as I’ve been working on it, I’ve been experimenting with a
> concrete “Path” type, similar to PathKit (https://github.com/kylef/
> PathKit/). Working in terms of AbsolutePath and RelativePath (what I’ve
> been calling things) has been *extremely* refreshing, because it allows
> me to better articulate the kind of data I’m dealing with. URL doesn’t
> handle pure-relative paths very well, and it’s always a bit of a mystery
> how resilient I need to be about checking .isFileURL or whatever. All the
> extra properties (port, user, password, host) feel hugely unnecessary as
> well.
>
> Dave
>
> On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I'm not convinced that URLs are the appropriate abstraction for a file
> system path. For the record, I'm not a fan of existing Foundation methods
> that create objects from an URL. There is a useful and fundamental
> difference between a local path and a remote path, and conflating the two
> has been a security pain point in many languages and frameworks that allow
> it. Examples include remote file inclusion in PHP and malicious doctypes in
> XML. Windows also had its share of issues with UNC paths.
>
> Even when loading an arbitrary URL looks innocuous, many de-anonymizing
> hacks work by causing a program to access an URL controlled by an attacker
> to make it disclose the user's IP address or some other identifier.
>
> IMO, this justifies that there should be separate types to handle local
> and remote resources, so that at least developers have to be explicit about
> allowing remote resources. This makes a new URL type less necessary towards
> supporting file I/O.
>
> Félix
>
> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> Okay so a few days ago there was a discussion
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html>
> about getting pure swift file system support into Foundation or another
> core library, and in my opinion, doing this requires a total overhaul of
> the `URL` type (which is currently little more than a wrapper for NSURL),
> so I’ve just started a pure Swift URL library project at <
> https://github.com/kelvin13/url>.
>
> The library’s parsing and validation core (~1K loc pure swift) is already
> in place and functional; the goal is to eventually support all of the
> Foundation URL functionality.
>
> The new `URL` type is implemented as a value type with utf8 storage backed
> by an array buffer. The URLs are just 56 bytes long each, so they should be
> able to fit into cache lines. (NSURL by comparison is over 128 bytes in
> size; it’s only saved by the fact that the thing is passed as a reference
> type.)
>
> As I said, this is still really early on and not a mature library at all
> but everyone is invited to observe, provide feedback, or contribute!
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170822/490fe945/attachment.html>