url.to_file_path() fails for unix:///C:/windows/path

[damonbarry]

Windows now supports Unix domain sockets.

If I parse a unix:// URL with a Windows path, then try to get the path back, I get an error:

extern crate url;
use url::Url;

fn main() {
    let path = "C:\\path\\to\\file";
    let file_url = "file:///C:/path/to/file";
    let unix_url = "unix:///C:/path/to/file";

    let mut one = Url::from_file_path(path).unwrap();
    let _ = one.set_scheme("unix").unwrap();
    assert_eq!(one.to_file_path().unwrap().as_os_str(), path);

    let two = Url::parse(file_url).unwrap();
    assert_eq!(two.to_file_path().unwrap().as_os_str(), path);

    let three = Url::parse(unix_url).unwrap();
    assert_eq!(three.to_file_path().unwrap().as_os_str(), path); // <-- panic!
}

PS C:\projects\rs-url-roundtrip> target\debug\rs-url-roundtrip.exe
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', libcore\result.rs:945:5

As the code shows, the from_file_path/to_file_path round trip works, as does the parse/to_file_path round trip for a file:// URL. It would be great if the parse/to_file_path worked for unix:// as well.

[nox]

Could you file an issue against https://github.com/whatwg/url? I don't think we should be doing things that are not actually specified in the URL Standard.

[okey]

As far as I can see, there's nothing in the whatwg url spec that forbids arbitrary non-special schemes such as unix://.

The question is, is it reasonable for to_file_path() to only work on file://? It probably is.

However, it might be nice to have a way to do same thing to non-special schemes that we expect to contain a path anyway.