Setting the scheme to "file" should fail if there's a host or port

[asajeffrey]

The test case:

    let mut url: Url = "http://localhost:6767/foo/bar".parse().unwrap();
    let result = url.set_scheme("file");
    assert_eq!(url.to_string(), "http://localhost:6767/foo/bar");
    assert_eq!(result, Err(()));

should pass, instead it fails with:

   (left == right)` (left: `"file://localhost:6767/foo/bar"`, right: `"http://localhost:6767/foo/bar"`)

The resulting URL has a file scheme, and a host/port, so serialization fails.

[asajeffrey]

This is the root cause of servo/servo#15435

[SimonSapin]

Should it really fail? This doesn’t match the spec at https://url.spec.whatwg.org/#dom-url-protocol

In this test case:

<a id=a href="http://example.net:8080/foo"></a>
<script>
var a = document.getElementById("a");
a.protocol = "file";
document.write(a.href)
</script>

Firefox prints file:///foo, Chromium prints file://example.net:8080/foo. I think we probably want to do like Firefox and remove the port implicitly.

@annevk Do you think the spec should be changed to remove the port in this case and avoid leaving the URL in an inconsistent state?

[annevk]

If you look at scheme state 2.1.3 it seems pretty clear there is a special case. It's not quite failure, but it shouldn't succeed.

[tmccombs]

https://url.spec.whatwg.org/#scheme-state

If url includes credentials or has a non-null port, and buffer is "file", then return.

If I understand this correctly, it means that setting the scheme to file for a URL that has credentials or a port specified should fail.

[annevk]

It's a no-op from the perspective of JavaScript, it doesn't throw. That's what I meant with not quite failure.

[tmccombs]

You're right @annevk.

[sanmai-NL]

@SimonSapin: Similarly, this library behaves counterintuitively when parsing a data URL.
See https://play.rust-lang.org/?gist=032d9d4e7724b68d74efec2daf07df35&version=stable
My reading of this discussion is that @tmccombs's #366 isn't an unreasonable approach in the end.

In the JavaScript console in the latest Firefox:

>> var parser = document.createElement('a');
>> parser.href = "data://localhost:80";
>> console.log(parser.protocol);
 http:
 undefined 

>> console.log(parser.host); 
 undefined

>> console.log(parser.hostname);
 undefined

>> console.log(parser.port); 
 undefined

Some weirdness with the protocol component/scheme, but no hostname or port number extracted from a data URL for sure.

[jdm]

@sanmai-NL Data URLs do not include the //.

[sanmai-NL]

@jdm: I know, a valid example is the counterexample in the Rust playground test case.

[annevk]

For a data URL that includes // Firefox is incorrect there as the URL parser doesn't special case data URLs.

[djc]

This passes the proposed test, so I'm guessing it can be closed. I added the test in 7b8b841 just to make sure.