urllib.request.pathname2url() mishandles UNC paths

[barneygale]

Bug report

Bug description:

When given a Windows UNC path, urllib.request.pathname2url() incorrectly generates a URI that begins with four slashes. The correct number is two, see ref1, ref2.

>>> import urllib.request
>>> urllib.request.pathname2url(r'\\server\share')
'////server/share'

Furthermore, when given an extended UNC path like \\?\unc\server\share, pathname2url() incorrectly generates a URI that begins with only one slash:

>>> urllib.request.pathname2url(r'\\?\unc\server\share')
'/server/share'

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

• GH-126205: Fix conversion of UNC paths to file URIs #126208
• [3.12] GH-126205: Fix conversion of UNC paths to file URIs (GH-126208) #126248
• [3.13] GH-126205: Fix conversion of UNC paths to file URIs (GH-126208) #126249

[serhiy-storchaka]

I do not think the case for \\server\share was a bug. file:////server/share and file://server/share are both acceptable. The latter form is more preferable, because it is generated on Windows by default, but I would not backport this change.

[barneygale]

file:////server/share and file://server/share are both acceptable.

The former is considered "incorrect" and "unhealthy" by the Microsoft docs:

Incorrect: file:////applib/products/a%2Db/ abc%5F9/4148.920a/media/start.swf
Correct: file://applib/products/a-b/abc_9/4148.920a/media/start.swf

The author of this URI was heading in the correct direction. They converted the backslashes in their Windows file path to forward slashes and they percent-encoded characters they thought should be encoded. Although they meant well, there are a couple of problems. First, ‘applib’ is meant to be the host, but is preceded by two extra slashes.

Also: https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775098(v=vs.85)#creating-file-schemes-from-file-paths

There are two kinds of file scheme URIs. The first is the well-formed, or "healthy," URL style that supports query strings, fragments, percent-encoded octets, and so on. The other is basically a DOS file path with "file://" prepended to the front. This latter form is generated when Uri_CREATE_FILE_USE_DOS_PATH is set and should be used only for legacy communication.

Warning: Legacy file scheme URIs should be used only with legacy APIs that will not accept healthy file scheme URIs. Legacy file scheme URIs do not allow percent encoded octets, which can lead to ambiguity. Therefore, legacy file scheme URIs should not be used unless absolutely necessary.

[barneygale]

I can revert this in 3.12 and 3.13 if you think that's the right thing to do!

[serhiy-storchaka]

No, I do not suggest to revert this in 3.12 and 3.13.

The Microsoft docs talk about abominations like file://C:\Windows\My Documents 100%20\file.txt and file://\\server\share\My Documents 100%20\file.txt, so I am not sure that it is related to URIs with correct slashes and escaping. Both RFC 8089 and the Wikipedia page refer to these forms as more or less equivalent. If percent-escaping, query and fragment are handled differently for these two forms, we have a larger issue.