55683 2011-03-03 09:27:21 -0800 KURL parses Windows-style absolute file: URLs incorrectly 2016-12-05 11:56:36 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) PC Windows XP RESOLVED DUPLICATE 162660 InRadar P2 Normal --- 1 aroben webkit-unassigned abarth achristensen ap brettw darin eric oldest_to_newest 361675 0 aroben 2011-03-03 09:27:21 -0800 Given a URL string like this: file://c:\foo\bar KURL will parse it into: file://c/foo/bar Note that the colon has disappeared. During parsing, KURL treats the colon as introducing a port number, then sees no port and just ignores it. A URL string like "file://localhost/c:\foo\bar" will be parsed correctly into "file://c:/foo/bar", however. 361681 1 ap 2011-03-03 09:33:08 -0800 Is this a regression, and is it normally observable? 361683 2 aroben 2011-03-03 09:35:45 -0800 I don't think it's a regression. It is observable in APIs like WKURLCreateWithUTF8CString correctly for Windows-style paths. See the workaround added in bug 55674, e.g. 361688 3 aroben 2011-03-03 09:38:47 -0800 I haven't tested whether it's a regression, though. 361696 4 aroben 2011-03-03 09:56:20 -0800 (In reply to comment #2) > It is observable in APIs like WKURLCreateWithUTF8CString correctly for Windows-style paths. I meant: it is obvservable in APIs like WKURLCreateWithUTF8CString, which are thus made hard to use correctly for Windows-style file: URLs. 361702 5 ap 2011-03-03 10:06:21 -0800 If it's a regression, then see also: bug 54090. 361711 6 eric 2011-03-03 10:15:05 -0800 I don't think this is a regression. file: urls are complicated, I've not done any work on them yet. :) See related results in: http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/file-expected.txt http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/relative-win-expected.txt 361714 7 aroben 2011-03-03 10:17:06 -0800 This result seems particularly relevant: FAIL canonicalize('//c:/foo') should be file:///C:/foo. Was file://c/foo. 361878 8 abarth 2011-03-03 13:11:17 -0800 File URLs are tricky. Most browsers parse them differently depending on whether they're running on Windows. Also, the three-slash versus two-slash question is pretty inconsistent. In any case, eating the ":" is definitely wrong. 361905 9 brettw 2011-03-03 13:48:34 -0800 Chrome has extensive Windows-only filename parsing rules that closely match IE's behavior. For some examples, see our unit tests: http://code.google.com/p/google-url/source/browse/trunk/src/url_canon_unittest.cc (search for "CanonicalizeFileURL" and you can see there is a big Windows-only block). 361918 10 abarth 2011-03-03 14:04:14 -0800 (In reply to comment #9) > Chrome has extensive Windows-only filename parsing rules that closely match IE's behavior. We're also running those tests as LayoutTests: http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/script-tests/file.js http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/file-expected.txt 365237 11 jberlin 2011-03-10 09:17:03 -0800 <rdar://problem/9114971> 1256419 12 achristensen 2016-12-05 11:56:36 -0800 URLParsing is now done according to spec. https://bugs.webkit.org/show_bug.cgi?id=162660 *** This bug has been marked as a duplicate of bug 162660 ***