[issue33327] Add a method to move messages to IMAPlib
Hans-Peter Jansen added the comment:
If I'm not mistaken, this is applied to the openSUSE TW version of Python.
For some reason, this seems to not play well with .uid('move',...)
on a cyrus imap server (v2.4.19). Is that to be expected?
```
2020-07-03 18:04:05 INFO: [imap_reorg] move b'10399' from 2017-01-01
06:30:35+02:00 to INBOX.2017
Traceback (most recent call last):
File "./imap_reorg.py", line 431, in
sys.exit(main())
File "./imap_reorg.py", line 425, in main
return process()
File "./imap_reorg.py", line 133, in trace_and_call
result = func(*args, **kwargs)
File "./imap_reorg.py", line 358, in process
ret |= reorg.run_expr(expr)
File "./imap_reorg.py", line 345, in run_expr
return method(*args)
File "./imap_reorg.py", line 328, in yearly
ret = self.imap.uid('move', uid, dest)
File "/usr/lib64/python3.8/imaplib.py", line 881, in uid
typ, dat = self._simple_command(name, command, *args)
File "/usr/lib64/python3.8/imaplib.py", line 1205, in _simple_command
return self._command_complete(name, self._command(name, *args))
File "/usr/lib64/python3.8/imaplib.py", line 1030, in _command_complete
raise self.error('%s command error: %s %s' % (name, typ, data))
imaplib.error: UID command error: BAD [b'Unrecognized UID subcommand']
```
--
nosy: +frispete
___
Python tracker
<https://bugs.python.org/issue33327>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Changes by Hans-Peter Jansen : -- nosy: +frispete ___ Python tracker <http://bugs.python.org/issue9253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28970] ctypes.from_buffer counterpart to actively remove the mapping
New submission from Hans-Peter Jansen: In an attempt of using ctypes.from_buffer() to map a structure to a memory mapped file, it is important to destroy the mapping after use, because the mmap won't be resizable or freeable correctly until then. The best approach, I was able to came up with is using a context manager, but calling the dtor of the mapping in __exit__ is not enough, which results to code like this: with StructMap(ctypes_struct, mm, offest) as smap: smap.xxx = 'blabla' del smap # necessary, but ugly Without the del, the "with" variable still exist in the local context, hence the mapping still exist, until it is explicitly destroyed. I hope, that ctypes is able to (or can be made to) actively remove the mapping in the __exit__ part of the context manager. I've put some code on stackoverflow to play with this: http://stackoverflow.com/questions/41077696/python-ctypes-from-buffer-mapping-with-context-manager-into-memory-mapped-file The problem seems to exist with the linux mmap implementation only. -- components: ctypes messages: 283188 nosy: frispete priority: normal severity: normal status: open title: ctypes.from_buffer counterpart to actively remove the mapping type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue28970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts
Hans-Peter Jansen added the comment: > (In msg271688, I pondered if I need to backport a behavior change from > issue26804 which will allow lower cased proxies, but then, I decided against > it as it will introduce unnecessary changes to this security fix releases). Hmm, Senthil, while I understand, that you want to avoid unnecessary changes, doesn't this result in non deterministic behaviour of proxy handling without my patch? + header. If you need to use an HTTP proxy in a CGI environment, either use + ``ProxyHandler`` explicitly, or make sure the variable name is in + lowercase (or at least the ``_proxy`` suffix). Without 26804, this fix works by chance only for 3.3 and 3.4, since it depends on os.environ dictionary order, which is non deterministic by definition. 26804 resolves this by making sure, a lower case _proxy var has a higher priority over the other variants. -- nosy: +frispete ___ Python tracker <http://bugs.python.org/issue27568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27513] email.utils.getaddresses raises exception from erroneous message get_all input
Hans-Peter Jansen added the comment: message.get cannot decode the header correctly, and returns a Header instance instead, which makes email.utils.getaddresses stumble upon... A much better behavior for getaddresses in this case would be returning the perfectly valid address, and ignoring the invalid dtext part. -- Added file: http://bugs.python.org/file43715/decode_from_header.py ___ Python tracker <http://bugs.python.org/issue27513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27513] email.utils.getaddresses raises exception from erroneous message get_all input
New submission from Hans-Peter Jansen:
An unfortunate combination of get_all and getaddresses results in a Traceback:
Traceback (most recent call last):
File "misc/decode_from_header.py", line 17, in
print('From: %s' % email.utils.getaddresses(val))
File "/usr/lib64/python3.4/email/utils.py", line 112, in getaddresses
all = COMMASPACE.join(fieldvalues)
TypeError: sequence item 0: expected str instance, Header found
Here's the relevant part of it:
Content-type: text/html;charset=iso-8859-1
From: Itaú Uniclass.
Obviously, the From header is iso-8859-1 encoded as well, and violates RFC 2822
as such. But making it crash in the usual combination of
val = msg.get('from')
email.utils.getaddresses([val])
isn't the real McCoy either..
--
components: email
files: iso-8859-1-encoded-from-header.mail
messages: 270399
nosy: barry, frispete, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.getaddresses raises exception from erroneous message get_all
input
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file43714/iso-8859-1-encoded-from-header.mail
___
Python tracker
<http://bugs.python.org/issue27513>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27256] email header indentation destroyed
Hans-Peter Jansen added the comment: Sorry guys for not providing this earlier. It turned out, that the sub optimal behaviour is related to a unfortunate policy choice: email.policy.SMTP. -- Added file: http://bugs.python.org/file43417/email_flatten.py ___ Python tracker <http://bugs.python.org/issue27256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27257] get_addresses results in traceback with an addrspec with an empty local part.
Hans-Peter Jansen added the comment: Sorry guys for not providing this earlier. It turned out, that the sub optimal behaviour is related to a unfortunate policy choice: email.policy.SMTP. -- Added file: http://bugs.python.org/file43416/email_flatten.py ___ Python tracker <http://bugs.python.org/issue27257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27258] Exception in BytesGenerator.flatten
Hans-Peter Jansen added the comment: Sorry guys for not providing this earlier. It turned out, that the sub optimal behaviour is related to a unfortunate policy choice: email.policy.SMTP. -- Added file: http://bugs.python.org/file43415/email_flatten.py ___ Python tracker <http://bugs.python.org/issue27258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: In a couple of systems, I have to stick with 3.4. Is there a chance to have this patch in 3.4 as well, if a new release 3.4 is made? -- ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27257] get_addresses results in traceback with a valid? header
Hans-Peter Jansen added the comment: Dear Stephen, thanks for your care. I'm glad, that you're able to reproduce it. This header is added from the email provider (the biggest here in Germany), so yes, it deserves an entry in the defects list, but must not traceback, of course. It is not expected to provide a sensible way of interoperability otherwise. The unlisted-recipients part is a bit more useful in this respect. -- ___ Python tracker <http://bugs.python.org/issue27257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27258] Exception in BytesGenerator.flatten
New submission from Hans-Peter Jansen: Attached mail, parsed with email.message_from_binary_file results in: Traceback (most recent call last): File "./mail_filter.py", line 616, in ret = main.run() File "./mail_filter.py", line 605, in run self.process(fp) File "./mail_filter.py", line 589, in process self.save_message(msg, self._fname + '.out') File "./mail_filter.py", line 103, in save_message ofd.write(msg.as_bytes()) File "/usr/lib64/python3.4/email/message.py", line 179, in as_bytes g.flatten(self, unixfrom=unixfrom) File "/usr/lib64/python3.4/email/generator.py", line 115, in flatten self._write(msg) File "/usr/lib64/python3.4/email/generator.py", line 195, in _write self._write_headers(msg) File "/usr/lib64/python3.4/email/generator.py", line 422, in _write_headers self._fp.write(self.policy.fold_binary(h, v)) File "/usr/lib64/python3.4/email/policy.py", line 190, in fold_binary folded = self._fold(name, value, refold_binary=self.cte_type=='7bit') File "/usr/lib64/python3.4/email/policy.py", line 204, in _fold return self.header_factory(name, ''.join(lines)).fold(policy=self) File "/usr/lib64/python3.4/email/headerregistry.py", line 255, in fold return header.fold(policy=policy) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 300, in fold self._fold(folded) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 1228, in _fold rest._fold(folded) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 338, in _fold if folded.append_if_fits(part, tstr): File "/usr/lib64/python3.4/email/_header_value_parser.py", line 149, in append_if_fits token._fold(self) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 324, in _fold for part in self.parts: File "/usr/lib64/python3.4/email/_header_value_parser.py", line 254, in parts if token.startswith_fws(): File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() IndexError: list index out of range when flattened with BytesGenerator. -- components: email files: flatten-exception.mail messages: 267736 nosy: barry, frispete, r.david.murray priority: normal severity: normal status: open title: Exception in BytesGenerator.flatten versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43288/flatten-exception.mail ___ Python tracker <http://bugs.python.org/issue27258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27257] get_addresses results in traceback with a valid? header
New submission from Hans-Peter Jansen:
In the course of replacing an old Python 2.7 email filter tool with a rewritten
Python3 version, I stumbled across a ugly case, where such an header:
To: unlisted-recipients: ;,
""@pop.kundenserver.de (no To-header on input)
results in a Traceback (most recent call last):
File "./mail_filter.py", line 606, in
ret = main.run()
File "./mail_filter.py", line 595, in run
self.process(fp)
File "./mail_filter.py", line 520, in process
config.recipients = self.get_addresses('to', msg)
File "./mail_filter.py", line 103, in get_addresses
vals = msg.get_all(field, [])
File "/usr/lib64/python3.4/email/message.py", line 511, in get_all
values.append(self.policy.header_fetch_parse(k, v))
File "/usr/lib64/python3.4/email/policy.py", line 145, in header_fetch_parse
return self.header_factory(name, ''.join(value.splitlines()))
File "/usr/lib64/python3.4/email/headerregistry.py", line 584, in __call__
return self[name](name, value)
File "/usr/lib64/python3.4/email/headerregistry.py", line 195, in __new__
cls.parse(value, kwds)
File "/usr/lib64/python3.4/email/headerregistry.py", line 342, in parse
for mb in addr.all_mailboxes]))
File "/usr/lib64/python3.4/email/headerregistry.py", line 342, in
for mb in addr.all_mailboxes]))
File "/usr/lib64/python3.4/email/_header_value_parser.py", line 837, in
local_part
return self[0].local_part
File "/usr/lib64/python3.4/email/_header_value_parser.py", line 889, in
local_part
return self[0].local_part
File "/usr/lib64/python3.4/email/_header_value_parser.py", line 984, in
local_part
tok[0].token_type == 'cfws'):
IndexError: list index out of range
I'm not completely sure, if the Top header, as added from my email provider, is
perfectly valid, but none of the other parts of my mail infrastructure neither
complained, nor behave strange with such headers.
This happens with 3.4.4, but also with the email module from current hg for
testing.
--
components: email
files: lkml-exception.mail
messages: 267733
nosy: barry, frispete, r.david.murray
priority: normal
severity: normal
status: open
title: get_addresses results in traceback with a valid? header
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43287/lkml-exception.mail
___
Python tracker
<http://bugs.python.org/issue27257>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27256] header indentation destroyed
Changes by Hans-Peter Jansen : Added file: http://bugs.python.org/file43286/mf.9__mi0bf.out ___ Python tracker <http://bugs.python.org/issue27256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27256] header indentation destroyed
New submission from Hans-Peter Jansen: In the course of replacing an old Python 2.7 email filter tool with a rewritten Python3 version, I stumbled across a ugly case, where such an header: X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJQUjAyTUI1MTQ7MjM6bEtRRlNaUHQvVTk5WCttdktlOUVrUGQvVFBH?= =?utf-8?B?cDFJemVUeXFzOGNzYnZOYWlwMDZpR0YzbXZyY09WaTBKM2pkeUl4S1VDMkxw?= =?utf-8?B?eVRkNWthRW9waUhJTzczTWd5WDZOQ3hMNU1haGFvQTVzVTdRZmxJUnZlblpW?= ... is regenerated as: X-Microsoft-Exchange-Diagnostics: 1;BL2PR02MB514;23:lKQFSZPt/U99X+mvKe9EkPd/TPG p1IzeTyqs8csbvNaip06iGF3mvrcOVi0J3jdyIxKUC2Lp yTd5kaEopiHIO73MgyX6NCxL5MahaoA5sU7QflIRvenZV which is plain wrong of course. I'm using email.message_from_binary_file for parsing and BytesGenerator.flatten for regeneration. Since those are LKML public mails, I'm attaching both versions. I'm using 3.4.4, but also the email module from current hg for testing. -- components: email files: utf8-header-failure.mail messages: 267732 nosy: barry, frispete, r.david.murray priority: normal severity: normal status: open title: header indentation destroyed versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43285/utf8-header-failure.mail ___ Python tracker <http://bugs.python.org/issue27256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10808] ssl unwrap fails with Error 0
Hans-Peter Jansen added the comment:
Poor old bug.
Just being bitten from it today, while trying to package pyftpdlib on the
openSUSE build service, which creates a clean reproducible build environment
for all packages, and testing fails.
Part of the game: openssl 1.0.1k, Python 2.7.8
https://build.opensuse.org/package/show/home:frispete:python/python-pyftpdlib
It happens reproducible for i586 only, but not for x86_64, with all the same
versions, and not with a local (much faster) build host.
So it is smells like a timing problem.
[ 97s] ERROR: test_nlst (test_functional_ssl.TestFtpListingCmdsTLSMixin)
[ 97s] --
[ 97s] Traceback (most recent call last):
[ 97s] File
"/home/abuild/rpmbuild/BUILD/pyftpdlib-1.5.1/pyftpdlib/test/test_functional_ssl.py",
line 139, in test_nlst
[ 97s] super(TestFtpListingCmdsTLSMixin, self).test_nlst()
[ 97s] File
"/home/abuild/.local/lib/python2.7/site-packages/pyftpdlib-1.5.1-py2.7.egg/pyftpdlib/test/test_functional.py",
line 1187, in test_nlst
[ 97s] self._test_listing_cmds('nlst')
[ 97s] File
"/home/abuild/.local/lib/python2.7/site-packages/pyftpdlib-1.5.1-py2.7.egg/pyftpdlib/test/test_functional.py",
line 1180, in _test_listing_cmds
[ 97s] self.client.retrlines('%s %s' % (cmd, tempdir), x.append)
[ 97s] File "/usr/lib/python2.7/ftplib.py", line 735, in retrlines
[ 97s] conn.unwrap()
[ 97s] File "/usr/lib/python2.7/ssl.py", line 289, in unwrap
[ 97s] s = self._sslobj.shutdown()
[ 97s] error: [Errno 0] Error
--
nosy: +frispete
___
Python tracker
<http://bugs.python.org/issue10808>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: v7: - reorder test code in order to improve edibility -- Added file: http://bugs.python.org/file42586/python-urllib-prefer-lowercase-proxies-v7.diff ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: > In Python 2, it looks like the proxy_bypass_etc() functions are defined > in urllib and imported into urllib2, so it makes sense to include the > tests in test_urllib rather than test_urllib2. The tests are in test_urllib. test_urllib2 is testing proxy behaviour on a higher level, so I think, they're in the correct module, aren't they? -- ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: * blatant error fixed * one test case added -- Added file: http://bugs.python.org/file42582/python-urllib-prefer-lowercase-proxies-v6.diff ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26831] ConfigParser parsing failures with default_section and ExtendedInterpolation options
New submission from Hans-Peter Jansen:
ConfigParser fails in interesting ways, when using default_section and
ExtendedInterpolation options. Running the attached script results in:
ConfigParser() with expected result:
global: [('loglevel', 'WARNING'), ('logfile', '-')]
section1: [('key_a', 'value'), ('key_b', 'morevalue')]
section2: [('key_c', 'othervalue'), ('key_d', 'differentvalue')]
ConfigParser(default_section='global') mangles section separation:
section1: [('loglevel', 'WARNING'), ('logfile', '-'), ('key_a', 'value'),
('key_b', 'morevalue')]
section2: [('loglevel', 'WARNING'), ('logfile', '-'), ('key_c', 'othervalue'),
('key_d', 'differentvalue')]
ConfigParser(interpolation=ExtendedInterpolation) fails with strange error:
Traceback (most recent call last):
File "configparser-test.py", line 36, in
print_sections(cp)
File "configparser-test.py", line 21, in print_sections
cp.read_string(__doc__)
File "/usr/lib64/python3.4/configparser.py", line 696, in read_string
self.read_file(sfile, source)
File "/usr/lib64/python3.4/configparser.py", line 691, in read_file
self._read(f, source)
File "/usr/lib64/python3.4/configparser.py", line 1089, in _read
self._join_multiline_values()
File "/usr/lib64/python3.4/configparser.py", line 1101, in
_join_multiline_values
name, val)
TypeError: before_read() missing 1 required positional argument: 'value'
while it is expected to behave identical.
--
components: Library (Lib)
files: configparser-test.py
messages: 264031
nosy: frispete
priority: normal
severity: normal
status: open
title: ConfigParser parsing failures with default_section and
ExtendedInterpolation options
versions: Python 3.4
Added file: http://bugs.python.org/file42573/configparser-test.py
___
Python tracker
<http://bugs.python.org/issue26831>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: v5: don't require the proxies argument in proxy_bypass_environment() -- Added file: http://bugs.python.org/file42565/python-urllib-prefer-lowercase-proxies-v5.diff ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: Here's the finalized version of this patch, including unit tests. -- Added file: http://bugs.python.org/file42552/python-urllib-prefer-lowercase-proxies-v4.diff ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: Here we go: v3 fixes following issues: * prefer lowercase proxy environment settings, if multiple (disagreeing) settings are specified with differing case schemes (e.g. HTTP_PROXY vs. http_proxy) * an empty proxy variable value resets the related setting correctly * apply this logic to no_proxy, too * document this behaviour * fix misleading docstrings related to proxy_bypass -- Added file: http://bugs.python.org/file42548/python-urllib-prefer-lowercase-proxies-v3.diff ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: Hi Martin, hi Senthil, please find a new patch attached, that incorporates your suggestions. * added a comment to get_proxies doc in urllib.rst * documented and fixed the mixed case scheme * added a note to proxy_bypass_environment, that behaves slightly different in this respect Yes, mixed case situations are not handled in proxy_bypass_environment, just lowercase and uppercase, while lowercase is preferred correctly. I think, that the mixed case situation is pathologic enough and deserves to be ignored here. BTW, while looking at the code, I noticed, that most docstrings of the callers of proxy_bypass_environment are wrong: they say, that the proxies dict is returned, but they return the value of proxy_bypass_environment(), not get_proxies(). A follow up patch could do this in order to clean up this mess: since there's always a call to get_proxies preceding the call to proxy_bypass_environment, we could add a second argument to the latter, passing in the proxy dict, that is thrown away at the moment. Since that carries a 'no' key already, if it exists, using it here would fix this ambiguity. While at it, fix up the affected docstrings. What do you think about the attached patch and the last paragraph? -- Added file: http://bugs.python.org/file42544/python-urllib-prefer-lowercase-proxies.diff ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Hans-Peter Jansen added the comment: Hi Martin, hi Senthil, thanks for the valuable comments. Will incorporate your suggestions later today. Yes, Martin, it's a bug, and should be fixed for 2.7 and 3.5 as well, but I was unsure, if I get some feedback at all... Hence, this is a very nice experience for me. I'm out for jogging now, Pete -- versions: +Python 2.7, Python 3.5 ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
Changes by Hans-Peter Jansen : -- versions: +Python 3.6 -Python 3.5 ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26804] Prioritize lowercase proxy variables in urllib.request
New submission from Hans-Peter Jansen: During programming a function, that replaces a wget call, I noticed, that something is wrong with urllibs proxy handling. I usually use the scheme "http_proxy= wget -N -nd URL" when I need to bypass the proxy. Hence I was pretty confused, that this doesn't work with python(3). Creating an empty ProxyHandler isn't the real Mc Coy either. Diving into the issue, I found getproxies_environment, but couldn't make much sense out of its behavior, up until I noticed, that my OS (openSUSE ) creates both variants of environment variables behind the scenes: uppercase and lowercase. Consequence: python3 needs the scheme "http_proxy= HTTP_PROXY= python3 ..." Since I, like everyone else, prefer gentle tones over the loud, and want to spare this surprise for others in the future, I propose the attached patch. Process environment variables in two passes, first uppercase, then lowercase, allowing an empty lowercase value to overrule any uppercase value. Please consider applying this. -- components: Extension Modules files: prioritize_lowercase_proxy_vars_in_urllib_request.diff keywords: patch messages: 263720 nosy: frispete priority: normal severity: normal status: open title: Prioritize lowercase proxy variables in urllib.request type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file42516/prioritize_lowercase_proxy_vars_in_urllib_request.diff ___ Python tracker <http://bugs.python.org/issue26804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Hans-Peter Jansen <[EMAIL PROTECTED]> added the comment:
Facundo, first of all: *really* nice work, thanks a lot.
While I don't fully understand the issues raised lately here,
especially what broke (user code). I can see, that it completely
solves my original problem, which is great.
While reading the patch, I noticed, that the modifications to
Doc/library/urllib2.rst contain two typos ("retrive" instead
of "retrieve").
The only remaining issue left in this area is using some form of
ordered dict for headers in order to control - how it comes - the
order of headers ;-), but that's left for another issue to raise some
day.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Hans-Peter Jansen <[EMAIL PROTECTED]> added the comment: Hi Senthil, that looks promising, and the title() trick is nice, as it fixes my issue.. Thanks, Pete __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2275> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Hans-Peter Jansen <[EMAIL PROTECTED]> added the comment: > But should not this patch be handled in a way wherein. > key.capitalize() is just replaced by key.upper()? Hmm, are you sure? >>> "hello".upper() 'HELLO' >>> but the issue is with values containing dashes: >>> 'accept-charset'.capitalize() 'Accept-charset' whereas the rest of the world would expect: 'Accept-Charset' ^ This is especially useful, if you try to emulate the behavior of a typical browser as close as possible. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2275> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
New submission from Hans-Peter Jansen <[EMAIL PROTECTED]>:
The urllib2 behavior related to headers is - hmm - improvable.
It simply capitalize() the key, which leads to funny results like:
Accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
while this is seemingly conforming to the specs, it's simply different
to every other implementation of such things..
And we can do better. How about:
--- /usr/lib/python/urllib2.py 2008-01-10 19:03:55.0 +0100
+++ urllib2.py 2008-03-11 21:25:33.523890670 +0100
@@ -261,13 +261,16 @@ class Request:
def is_unverifiable(self):
return self.unverifiable
+def _cap_header_key(self, key):
+return '-'.join((ck.capitalize() for ck in key.split('-')))
+
def add_header(self, key, val):
# useful for something like authentication
-self.headers[key.capitalize()] = val
+self.headers[self._cap_header_key(key)] = val
def add_unredirected_header(self, key, val):
# will not be added to a redirected request
-self.unredirected_hdrs[key.capitalize()] = val
+self.unredirected_hdrs[self._cap_header_key(key)] = val
def has_header(self, header_name):
return (header_name in self.headers or
I'm not happy with the _cap_header_key name, but you get the idea.
The patch is optimized to operate with maximum locality. It's also
attached.
I would be very grateful, if something similar could be applied.
Opinions?
--
components: Library (Lib)
files: urllib2-cap-headers.diff
keywords: patch
messages: 63466
nosy: frispete
severity: minor
status: open
title: urllib2 header capitalization
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9658/urllib2-cap-headers.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
