- From: Felix Becker <notifications@github.com>
- Date: Fri, 28 Apr 2017 03:46:15 -0700
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Friday, 28 April 2017 10:46:48 UTC
Edge keeps the host, but throws an Invalid URL Error upon serializing with `href` or `toString()`: ![image](https://cloud.githubusercontent.com/assets/10532611/25525434/37a1b502-2c0f-11e7-9a14-7dc5a0771ed0.png) So it doesn't really follow the spec either, but if they changed it to support this it wouldn't be a breaking change. There is no indication why it would _not_ be a valid location, and why it would be valid for remote Unix machines but not for remote Windows machines. Imagine you have an application running on machine A that identifies files by file URIs (e.g. an editor), then passes these in some way to another server or container B (e.g. a language intelligence server). For the external server, the files are not on `localhost` anymore, but on a different host. To prevent him from trying to read the files from his local disk, a host component should be added to the URI. This use case works 100% fine if A is running Unix, but not when A is running Windows, and I don't see a reason why it shouldn't. The URI just says "Hey, the file is on the file system of this host under this path". -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/302#issuecomment-297967757
Received on Friday, 28 April 2017 10:46:48 UTC