incomplete proxy handling in URLLIB

[anonymous]

BPO	403640
Nosy	@gvanrossum, @tim-one
Files	None: None

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tim-one'
closed_at = <Date 2001-08-09.18:06:03.000>
created_at = <Date 2001-02-06.14:57:58.000>
labels = ['library']
title = 'incomplete proxy handling in URLLIB'
updated_at = <Date 2001-08-09.18:06:03.000>
user = 'https://bugs.python.org/anonymous'

bugs.python.org fields:

activity = <Date 2001-08-09.18:06:03.000>
actor = 'tim.peters'
assignee = 'tim.peters'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2001-02-06.14:57:58.000>
creator = 'anonymous'
dependencies = []
files = ['3092']
hgrepos = []
issue_num = 403640
keywords = ['patch']
message_count = 6.0
messages = ['35585', '35586', '35587', '35588', '35589', '35590']
nosy_count = 2.0
nosy_names = ['gvanrossum', 'tim.peters']
pr_nums = []
priority = 'low'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue403640'
versions = []

[nobody]

under WinNT, the proxy code takes the proxy values from the registry, but does *not* check for the proxy override settings. The supplied patch does take care of it and works for me. Not very sophisticated, but operational.

[gvanrossum]

Logged In: YES
user_id=6380

Tim, you seem to be using a proxy, so maybe you can give
this a try?
Also, it has Win specific code (_winreg usage).

If you can't or don't want to, please give it back.

[tim-one]

Logged In: YES
user_id=31435

Back to you! I've spent enough time on it, but I don't
know this code, and it turns out I never get into it
anyway. @Home uses the AutoConfigURL registry gimmick
rather than ProxyEnable (which is 0 on my box) and
ProxyOverride (which doesn't exist on my box).

Even if they did exist, the new proxy_bypass() routine
isn't called if the url passed to open_http() is a string,
and it always is a string for me. Trying to trace *that*
back, this is apparently because the NT getproxies()
function returns {}, and again because @Home isn't enabling
ProxyEnable.

So best I can say is that this code doesn't hurt me.

Note that there are jarring style differences with
surrounding code, primarily use of Capitalized words for
local vrbl names. Also lines and comments spilling past
column 80. The list() call in

list(proxyOverrd.split(';'))

doesn't appear to make sense (.split() returns a list!).
For that matter proxyOverrd is an ugly abbreviation.

[gvanrossum]

Logged In: YES
user_id=6380

Back to you, Tim. I'm also an @home user so I can't test this either.

I agree with the style comments.

Also, it translates a pattern to regular expression; an easier way to do this is to use fnmatch (which also takes
care of the case insensitive match when it's on Windows).

Would the original submitter care to clean up the code according to the (Tim's & my) comments?

Otherwise I think this is sufficiently low priority that I'm not going to move heaven & earth to get it into 2.1b2 (this
Friday), and after that I'm not going to allow *anything* new in the code base for 2.1.

[gvanrossum]

Logged In: YES
user_id=6380

I'm accepting this. The original submitter didn't care to
clean it up, so I'm lowering the priority. Tim, just check
it in -- if it's broken we'll hear about it.

[tim-one]

Logged In: YES
user_id=31435

Cleaned up the most egregious style clashes, and checked in:

Lib/urllib.py, new revision: 1.129

Don't know whether it works. Didn't bother with fnmatch
(simply because I'm not going to make substantive changes
to code I don't understand and can't test).