This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23550 - file URL parsing issues
Summary: file URL parsing issues
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
URL:
Whiteboard:
Keywords:
Depends on: 27518
Blocks:
  Show dependency tree / graph
 
Reported: 2013-10-17 16:46 UTC by Anne
Modified: 2015-08-14 06:17 UTC (History)
5 users (show)

See Also:

Attachments

Description Anne 2013-10-17 16:46:31 UTC 
See https://github.com/annevk/url/issues/1

From Domenic:

var base = new URL("file:///C:/Users/Domenic/Dropbox/Programming/GitHub/jsdom/test/jsdom/index.js");

var resolved = new URL("/", base);

console.log(resolved.href);

Gives "file:///", but should give "file:///C:/".
Comment 1 Anne 2013-11-20 15:51:24 UTC 
http://code.google.com/p/chromium/issues/detail?id=257354 has other cases the specification is not handling. file URLs definitely need more research :/
Comment 2 Larry Masinter 2014-11-18 18:14:09 UTC 
I wonder if it might be better to treat looking for and resolving "file:" URIs might be best described as a preprocessor, that web applications would use and non-web applications might leave out.
Comment 3 Anne 2015-08-13 15:39:28 UTC 
It would be interesting to have the results for these:

  / against file:///
  / against file://x/
  / against file:///C:/
  /C|/ against file:///
  /C:/ against file://x/
  /C:/ against file:///C:/
Comment 4 Anne 2015-08-13 15:47:25 UTC 
And those tests, but then with the input prefixed with "file:", just to make sure.