This fixes HandlerTests.test_file() on Windows. Hope it works -- I don't have 2.4 CVS on Windows. Also cleaned up testing of generated Last-Modified header. Still needs testing on Mac. I had to introduce a sanepathname2url() to replace urllib.pathname2url(). I don't understand why urllib.pathname2url() behaves as it does (returning a path starting with three slashes /// instead of one) -- seems wrong according to RFC 1738. Should it be fixed in urllib?
Logged In: YES user_id=31435 I confirm that the patch allows test_urllib2 to pass again on Windows. Assigned to Jeremy, as I made no attempt to try to understand what the patch does.
Logged In: YES user_id=764593 Today, a missing host or protocol indicates a relative URL. At one point, it could also have meant file (or ftp) to the localhost. proto://host/path -> file://localhost/path -> //localhost/path -> ///path Therefore, ///path == //localhost/path, which may well be different from BASEURI/path. Note that on unix, /path is well-defined, but on windows, it isn't. It should probably map to C:\path, unless there is already a driver letter in path -- and I believe that old enough browsers supported paths with or without a driver letter. I do not know what the Mac equivalent of /path should be. I suspect the least bad choice for /// is to keep doing whatever it did before.
Logged In: YES user_id=261020 I fear you're right that "fixing" urllib.pathname2url is a bad idea for backwards-compatibility reasons. Anyway, ISTR file: URLs with one, two and three slashes, so I guess I have to admit standardization has failed here. For the record, though: You're supposed to have those extra two slashes in a *full* URL on unix, too. But the docs say: ------ Convert the pathname path from the local syntax for a path to the form used in the path component of a URL. This does not produce a complete URL. ------ RFC 1738, section 3.10, makes it clear that the path component of a file: URL doesn't include those first two slashes (actually, it's claims the third isn't, either, presumably just to be subtly different from the generic syntax of RFC 2396 - argh!). Your point about unix vs. Windows is not relevant: the path component of a file: URL isn't supposed to be directly interpreted as an OS filesystem path (RFC 1738 gives a VMS example).
