[Patches] [ python-Patches-870606 ] make test_urllib2 work on Windows

[SourceForge.net]

Patches item #870606, was opened at 2004-01-04 23:48
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470

Category: Tests
Group: Python 2.4
Status: Closed
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: make test_urllib2 work on Windows

Initial Comment:
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? 

----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2004-07-10 11:34

Message:
Logged In: YES 
user_id=261020

Closed because patch has been applied.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-01-10 14:52

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

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-01-08 21:03

Message:
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.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-01-04 23:58

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470