[ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 10:29
Message generated for change (Comment added) made by jerrykhan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3
Initial Comment:
My python app had to retrieve some web pages and while
our network environment requires proxy it uses urllib2
opener (source is in attachment). It worked very well
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310
32 bit (Intel)] on win32
It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK. We have reply from http://www.python.org.
Size: 13757 [b]
http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
http://www.w3.org/
1999/xhtml">
design by pollenation
Copyright Š 1990-2006, Python Software
Foundation
Legal Statements
isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
File "proxy_bug.py", line 37, in ?
get_page()
File "proxy_bug.py", line 27, in get_page
f = urllib2.urlopen(request)
File "/usr/local/lib/python2.4/urllib2.py", line
130, in urlopen
return _opener.open(url, data)
File "/usr/local/lib/python2.4/urllib2.py", line
364, in open
response = meth(req, response)
File "/usr/local/lib/python2.4/urllib2.py", line
471, in http_response
response = self.parent.error(
File "/usr/local/lib/python2.4/urllib2.py", line
402, in error
return self._call_chain(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
337, in _call_chain
result = func(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
480, in http_error_default
raise HTTPError(req.get_full_url(), code, msg,
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy
Authentication Required
I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I
first spot this bug on their destribution but it seems
that bug is in others distributions too.
Regards,
Michal Niklas
--
Comment By: JerryKhan (jerrykhan)
Date: 2006-11-28 16:17
Message:
Logged In: YES
user_id=867168
Originator: NO
Hello,
In my sens in a general manner there is something wrong in the urllib2
http code:
But this may depends on the environment (I am not an expert in urllib)
Here are my tests : using python 2.4.2 on Windows XP
These simple codes failed with a 407 http error :
Example E1:
import urllib2 as URL
a=URL.urlopen("http://lan_apache_url";)
print a.read()
OR example E2:
import urllib2 as URL
r=URL.Request("http://lan_apache_url";)
a=URL.urlopen(r)
print a.read()
But succeed with urllib example E3
import urllib
a=urllib.urlopen("http://lan_apache_url";)
print a.read()
Notice that different code lines are minimal E1 and E3 are close:
Notice also that I'm try to access a lan apache server which is not behind
a Proxy.
And I don't want to access to any Proxy (like exclusion string in
IExplorer)
But I found also that If I try to access to a protected link with HTTPS
... on the LAN, there is not problem. The issue is really on the HTTP
interpreter or during the configuration of the URL opener.
In the same time, some of my programs are able to access to Internet
servers using the current Proxy server without any problem. For that, I
use:
import urllib2 as URL
URL.install_opener(URL.build_opener( s.https_handler,
s.proxy_auth_handler, s.cookie_handler))
Well, I developed a workaround in my programs ... to use urllib instead of
urllib2 in the case where I try to access the LAN (in fact when I don't
want to configure the Proxy server, or when the URL match my own proxy
exclusion list.)
I espect this will help python urllib2 experts to find the issue.
Jérôme Vacher alias jerrykhan the foolish dracomorpheus of the emerald
dragon dynasty.
--
Comment By: Michal Niklas (mniklas)
Date: 2006-07-21 09:59
Message:
Logged In: YES
user_id=226518
I have just installed new virtual machine with Python 2.5b2
and my program works. It seems that only 2.4.3 is broken.
Regards,
Michal
--
Comment By: John J
[ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error
Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/
[ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils
Bugs item #1530142, was opened at 2006-07-28 16:02 Message generated for change (Comment added) made by richard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Jones (richard) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Mac Universal Build of Python confuses distutils Initial Comment: I'm sorry I can't provide a fully-detailed report here, but I'm not in a position to be able to reproduce the problem. In short, I installed the Universal build of Python 2.4.3 for the Mac downloaded from: http://pythonmac.org/packages/py24-fat/index.html I don't know whether this is the same as the download from: http://www.python.org/download/releases/2.4.3/ Once installed, I attempted to build ctypes. The build failed due to an assembly error (unknown instruction). I'm not familiar with the PPC or x86 assembler code so couldn't do a thorough analysis. I needed Python2.4 to work, so I found an older PPC-only installer and used that. -- >Comment By: Richard Jones (richard) Date: 2006-11-29 08:56 Message: Logged In: YES user_id=6405 Originator: YES I just successfully built ctypes 1.0.1 on a MacBook (ie. x86) OS X machine. I don't know whether it builds on a PPC machine. -- Comment By: Richard Jones (richard) Date: 2006-08-17 07:52 Message: Logged In: YES user_id=6405 I successfully built ctypes on PPC OSX using a non-universal build. Also, I wasn't running on x86 OSX so it shouldn't have tried to build that. -- Comment By: Martin v. Löwis (loewis) Date: 2006-08-16 23:25 Message: Logged In: YES user_id=21627 This might be a ctypes limitation: it might be that ctypes doesn't support x86-OSX (atleast in this release). -- Comment By: Richard Jones (richard) Date: 2006-07-28 16:47 Message: Logged In: YES user_id=6405 0.9.9.6 -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-28 16:28 Message: Logged In: YES user_id=580910 Which version of ctypes did you try to build? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1604851 ] subprocess.Popen closes fds for sys.stdout or sys.stderr
Bugs item #1604851, was opened at 2006-11-28 14:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604851&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nishkar Grover (ngrover)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.Popen closes fds for sys.stdout or sys.stderr
Initial Comment:
I found a problem in subprocess.Popen's _execute_child() method for POSIX,
where the child process will close the fds for sys.stdout and/or sys.stderr if
I use those as stdout and/or stderr when creating a subprocess.Popen object.
Here's what I saw by default when using the 2.4.4 version of Python...
% ./python
Python 2.4.4 (#1, Nov 28 2006, 14:08:29)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import sys, subprocess
>>> uname = subprocess.Popen('uname -a', shell=True, stdout=sys.stdout)
>>> uname: write error: Bad file descriptor
>>>
Then, I updated subprocess.py and made the following changes...
% diff subprocess.py subprocess.py.orig
924c924
< # fd more than once and don't close sys.stdout or
sys.stderr.
---
> # fd more than once.
927c927
< if c2pwrite and c2pwrite not in (p2cread,
sys.stdout.fileno(), sys.stderr.fileno()):
---
> if c2pwrite and c2pwrite not in (p2cread,):
929c929
< if errwrite and errwrite not in (p2cread, c2pwrite,
sys.stdout.fileno(), sys.stderr.fileno()):
---
> if errwrite and errwrite not in (p2cread, c2pwrite):
After that, I saw the following...
% ./python
Python 2.4.4 (#1, Nov 28 2006, 14:08:29)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import sys, subprocess
>>> uname = subprocess.Popen('uname -a', shell=True, stdout=sys.stdout)
>>> Linux schnauzer 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006 i686
>>> i686 i386 GNU/Linux
>>>
I'm attaching the modified version of subprocess.py. Please consider adding
this fix to future versions of Python. Thanks!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604851&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1604862 ] _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8
Bugs item #1604862, was opened at 2006-11-28 22:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: William Fulton (wsfulton) Assigned to: Nobody/Anonymous (nobody) Summary: _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 Initial Comment: I'm getting this warning with VC++ 8 for all extension modules: e:\python25\include\pyconfig.h(42) : warning C4005: '_CRT_SECURE_NO_DEPRECATE' : macro redefinition .\example_wrap.cxx(124) : see previous definition of '_CRT_SECURE_NO_DEPRECATE' because Python.h defines this macro without checking that it is not already defined. Can you fix your headers so we don't get this warning? It is impossible to work around this problem when dealing with multiple versions of Python as we can't detect the version of Python until Python.h is parsed - a catch 22 situation. Can you use the same approach that we are using in SWIG? This is what we do: #if !defined(SWIG_NO_CRT_SECURE_NO_DEPRECATE) && defined(_MSC_VER) && !defined(_CRT_SECURE_NO_DEPRECATE) # define _CRT_SECURE_NO_DEPRECATE #endif Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
