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

Logged In: YES 
user_id=261020

Closed because patch has been applied.