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

[Taylor Swift]

I think that’s more a problem that lies in Foundation methods that take
URLs rather than the URLs themselves. A URL is a useful abstraction because
it contains a lot of common functionality between local file paths and
internet resources. For example, relative URI reference resolution. APIs
which take URLs as arguments should be responsible for ensuring that the
URL’s schema is a `file:`. The new URL type I’m writing actually makes the
scheme an enum with cases `.file`, `.http`, `.https`, `.ftp`, and `.data`
to ease checking this.

On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier <felixcloutier at icloud.com>
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170821/1685495f/attachment.html>