localhost (original) (raw)

Per RFC 1738 section 3.10: "A file URL takes the form: file:/// ... As a special case, can be the string "localhost" or the empty string; this is interpreted as `the machine from which the URL is being interpreted".

In other words, regardless of what DNS or NetBIOS say about "localhost", it is always the local machine.

Therefore, functions like urllib.url2pathname() and urllib.urlopen() and anything else that takes a URL argument should treat '///path/to/file' and '//localhost/path/to/file' identically, returning '/path/to/file' on Unix or '\path\to\file' on Windows, for example.

(note separate bug report filed for url2pathname() mishandling '///path/to/file' on Windows)

Logged In: YES user_id=371366

I didn't realize it was a duplicate. I'm OK with the resolution of #607789. So I am changing this one to Closed / Duplicate.

In hindsight, I feel there are so many little conformance bugs in urllib that are so entrenched, there's no reason to assume that true RFC conformance was ever the intent or that it is a reasonable goal. Much code out there, within core Python libs and without, is written to match urllib's current behavior, or vice-versa.

If anyone's curious, I have implemented some urllib workarounds and RFC 2396bis (new version of RFC 2396, the URI spec) compliant features in 4Suite's Ft.Lib.Uri module, which can be reviewed at http://cvs.4suite.org/cgi- bin/viewcvs.cgi/~~checkout~~/4Suite/Ft/Lib/Uri.py? rev=HEAD&content-type=text/plain ... it's always a work in progress, but is getting close to having a fork stuck in it for our upcoming 1.0 release.