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

[Taylor Swift]

that might be true but I’d need to hear from more people to justify
creating two very similar URI types. Technically `file:` is just a string
that the file system interpreter gives meaning to; the scheme of a URL can
be any alphanumeric string. For example you could write a file manager
which interprets "foo:" as a local address, or ignore the scheme entirely.

On Mon, Aug 21, 2017 at 11:23 AM, Félix Cloutier <felixcloutier at icloud.com>
wrote:

> There's no question that there's a lot in common between file: URLs and
> other URLs, but that hardly makes URLs better in the file: case.
>
> I saw the enum. The problem remains that it's a common API principle to
> accept the broadest possible input. It's not fundamentally wrong to accept
> and resolve common URL types, as there's a ton of things that need to read
> documents from the Internet by design. However, if this is the default
> facility for file handling too, it invents either:
>
>
>    - A responsibility for API users to check that their URL is a file:
>    URL;
>    - A responsibility for API authors to provide separate entry points
>    for file URLs and remote URLs, and a responsibility for API users to use
>    the right one.
>
>
> It would also add a category of errors to common filesystem operations:
> "can't do this because the URL is not a file: URL", and a category of
> questions that we arguably shouldn't need to ask ourselves. For instance,
> what is the correct result of glob()ing a file: URL pattern with a hash or
> a query string, should each element include that hash/query string too?
>
> Félix
>
> Le 20 août 2017 à 23:33, Taylor Swift <kelvin13ma at gmail.com> a écrit :
>
> 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/5dbc36cb/attachment.html>