Bug 55683 – KURL parses Windows-style absolute file: URLs incorrectly

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebCore Misc.

[Adam Roben (:aroben)]

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.

[Alexey Proskuryakov]

Is this a regression, and is it normally observable?

[Adam Roben (:aroben)]

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.

[Adam Roben (:aroben)]

I haven't tested whether it's a regression, though.

[Adam Roben (:aroben)]

(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.

[Alexey Proskuryakov]

If it's a regression, then see also: bug 54090.

[Eric Seidel (no email)]

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

[Adam Roben (:aroben)]

This result seems particularly relevant:

FAIL canonicalize('//c:/foo') should be file:///C:/foo. Was file://c/foo.

[Adam Barth]

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.

[Brett Wilson (Google)]

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).

[Adam Barth]

(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

[Jessie Berlin]

<rdar://problem/9114971>

[Alex Christensen]

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 ***