- From: James Graham <james@hoppipolla.co.uk>
- Date: Fri, 6 May 2016 13:39:09 +0100
- To: "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
In the spec currently it is unclear how URLs are parsed/resolved with the Go command[1]. It is not quite clear from the HTML Navigate algorithm what happens when you pass it something other than an absolute URL, yet we just blindly pass it the user-supplied string. Therefore I conclude that we are responsible for ensuring that we pass it something that is an absolute URL. There are two cases we have to consider: 1) Strings that cannot be parsed as any kind of URL e.g. "http://a]b" I am of the opinion that we should return an error in these cases because the probability that someone is trying to test invalid url handling is much smaller than the probability that they have made a typo. 2) Strings that are not absolute URLs, but could be relative urls e.g. "foo" or "example.org". I am of the opinion that we should treat these as relative URLs and resolve them relative to the current document, as would happen if they were in links. This has the benefit of being a useful feature (you can navigate to resources without always having to construct an absolute URL in the client) and being simple to specify. It does mean that people can't pass in schemeless URLs and expect them to be converted into http[s] urls, or whatever, but a client could implement that behaviour if it desired. In the case that a string can't be treated as a relative URL e.g. because the scheme doesn't support relative URLs (e.g. data:), I believe an error should be returned. [1] Side note: I think the name "Get" was better. It causes the browser to GET a particular URL. Seems clear enough.
Received on Friday, 6 May 2016 12:41:47 UTC