[ python-Bugs-1486335 ] httplib: read/_read_chunked failes with ValueError sometime
Bugs item #1486335, was opened at 2006-05-11 11:14 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=1486335&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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: httplib: read/_read_chunked failes with ValueError sometime Initial Comment: This occasionally shows up in a logged trace, when a application crahes on ValueError on a http(s)_response.read() : (py2.3.5 - yet relevant httplib code is still the same in current httplib) \' File "socket.pyo", line 283, in read\\n\', \' File "httplib.pyo", line 389, in read\\n\', \' File "httplib.pyo", line 426, in _read_chunked\\n\', \'ValueError: invalid literal for int(): \\n\'] ::: its the line: chunk_left = int(line, 16) Don't know what this line is about. Yet, that should be protected, as a http_response.read() should not fail with ValueError, but only with IOError/EnvironmentError, socket.error - otherwise Error Exception handling becomes a random task. -Robert Side note regarding IO exception handling: See also FR #1481036 (IOBaseError): why socket.error.__bases__ is (,) ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&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: 8
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
--
>Comment By: kxroberto (kxroberto)
Date: 2006-05-11 14:05
Message:
Logged In: YES
user_id=972995
Testing it with Python2.5a2, the problem is still there.
Without the .shutdown(2) (or .shutdown(1)) patch to the
httplib.SharedSocket (base for FakeSocket), the ftps example
freezes on the cmd channel, because the SSL'ed data channel
doesn't close/terminate --> FTPS server doesn't respond on
the cmd channel. The ftps example is most specific to show
the bug.
Yet you can also easily blow up a HTTPS-server with this
decent test code who only opens (bigger!) files and closes
without reading everything:
Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
Robert's Interactive Python - TAB=complete
import sys,os,re,string,time,glob,thread,pdb
>>> import urllib
>>> l=[]
>>> for i in range(10):
...f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz')
...f.close()
...l.append(f)
...
>>>
=> in the (apache) servers ssl_engine_log you can see that
connections remain open (until apache times out after 2
minutes) and lots of extra apache daemons are started!
=> f.close() doesn't really close the connection (until it
is __del__'ed )
Trying around I found that the original undeleted f.fp._ssl
is most probably the cause and holds the real socket open.
a f.fp._sock.close() doesn't close also - but only when del
f.fp._ssl is done. (only a f.fp._sock._sock.close() would
force the close). The original fp is held in closures of
.readline(s)/__iter__/next...
--
I now tried an alternative patch (instead of the
shutdown(2)-patch), which also so far seems to cure
everything . Maybe thats the right solution for the bug:
--- httplib.py.orig 2006-05-11 11:25:32.0 +0200
+++ httplib.py 2006-05-11 13:45:07.0 +0200
@@ -970,6 +970,7 @@
self._shared.decref()
self._closed = 1
self._shared = None
+self._ssl = None
class SSLFile(SharedSocketClient):
"""File-like object wrapping an SSL socket."""
@@ -1085,6 +1086,7 @@
def close(self):
SharedSocketClient.close(self)
self._sock = self.__
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 17: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=1486663&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: dib (dib_at_work) Assigned to: Nobody/Anonymous (nobody) Summary: Over-zealous keyword-arguments check for built-in set class Initial Comment: The fix for bug #1119418 (xrange() builtin accepts keyword arg silently) included in Python 2.4.2c1+ breaks code that passes keyword argument(s) into classes derived from the built-in set class, even if those derived classes explictly accept those keyword arguments and avoid passing them down to the built-in base class. Simplified version of code in attached BuiltinSetKeywordArgumentsCheckBroken.py fails at (G) due to bug #1119418 if version < 2.4.2c1; if version >= 2.4.2c1 (G) passes thanks to that bug fix, but instead (H) incorrectly-in-my-view fails. [Presume similar cases would fail for xrange and the other classes mentioned in #1119418.] -- David Bruce (Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 17:17 Message generated for change (Settings changed) made by dib_at_work You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: dib (dib_at_work) Assigned to: Nobody/Anonymous (nobody) Summary: Over-zealous keyword-arguments check for built-in set class Initial Comment: The fix for bug #1119418 (xrange() builtin accepts keyword arg silently) included in Python 2.4.2c1+ breaks code that passes keyword argument(s) into classes derived from the built-in set class, even if those derived classes explictly accept those keyword arguments and avoid passing them down to the built-in base class. Simplified version of code in attached BuiltinSetKeywordArgumentsCheckBroken.py fails at (G) due to bug #1119418 if version < 2.4.2c1; if version >= 2.4.2c1 (G) passes thanks to that bug fix, but instead (H) incorrectly-in-my-view fails. [Presume similar cases would fail for xrange and the other classes mentioned in #1119418.] -- David Bruce (Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 16:17 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: dib (dib_at_work) >Assigned to: Raymond Hettinger (rhettinger) Summary: Over-zealous keyword-arguments check for built-in set class Initial Comment: The fix for bug #1119418 (xrange() builtin accepts keyword arg silently) included in Python 2.4.2c1+ breaks code that passes keyword argument(s) into classes derived from the built-in set class, even if those derived classes explictly accept those keyword arguments and avoid passing them down to the built-in base class. Simplified version of code in attached BuiltinSetKeywordArgumentsCheckBroken.py fails at (G) due to bug #1119418 if version < 2.4.2c1; if version >= 2.4.2c1 (G) passes thanks to that bug fix, but instead (H) incorrectly-in-my-view fails. [Presume similar cases would fail for xrange and the other classes mentioned in #1119418.] -- David Bruce (Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 16:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: dib (dib_at_work) Assigned to: Raymond Hettinger (rhettinger) Summary: Over-zealous keyword-arguments check for built-in set class Initial Comment: The fix for bug #1119418 (xrange() builtin accepts keyword arg silently) included in Python 2.4.2c1+ breaks code that passes keyword argument(s) into classes derived from the built-in set class, even if those derived classes explictly accept those keyword arguments and avoid passing them down to the built-in base class. Simplified version of code in attached BuiltinSetKeywordArgumentsCheckBroken.py fails at (G) due to bug #1119418 if version < 2.4.2c1; if version >= 2.4.2c1 (G) passes thanks to that bug fix, but instead (H) incorrectly-in-my-view fails. [Presume similar cases would fail for xrange and the other classes mentioned in #1119418.] -- David Bruce (Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-05-11 17:23 Message: Logged In: YES user_id=849994 Raymond, what to do in this case? Note that other built-in types, such as list(), do accept keyword arguments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486897 ] OS X framework build for python 2.5 fails, configure is odd
Bugs item #1486897, was opened at 2006-05-11 14:44 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=1486897&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: Open Resolution: None Priority: 5 Submitted By: Christopher Knox (vizowl) Assigned to: Nobody/Anonymous (nobody) Summary: OS X framework build for python 2.5 fails, configure is odd Initial Comment: The OS X framework build for python 2.5 does not install a dynamic library at /Library/Frameworks/Python.framework/Versions/2.5/Python where it should. The python2.5 executible does not run because it is trying to load this dynamic library. This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2. Also all of the extra modules (_CG extension, IDLE extra) fail to link because their link command is -lpython2.5 which is not what it should be for a framework build and even if it was correct for linking agianst a framework it would fil because the framework doesn't have its library anyway. Finally, the configure script behaves oddly in that it works fine, but if you change the parameters and rerun it it will fail unless you run 'make distclean' This is where it fails. checking whether mmap with MAP_ANON(YMOUS) works... yes configure: error: "libffi has not been ported to i686-apple-darwin8.6.1." Failed to configure _ctypes module -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-944394 ] No examples or usage docs for urllib2
Bugs item #944394, was opened at 04/29/04 04:02 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&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: None >Status: Closed Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris -- >Comment By: SourceForge Robot (sf-robot) Date: 05/11/06 19:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 04/27/06 06:06 Message: Logged In: YES user_id=849994 Chris, I concur with jjlee that suggesting examples is the best way to get something done. Perhaps, if you're using urllib2, you could flesh out some examples from your code? -- Comment By: John J Lee (jjlee) Date: 04/17/06 07:26 Message: Logged In: YES user_id=261020 Do you have any specific suggestions for what is unhelpful and/or missing? Otherwise, nothing is likely to change. Note that a little was added at the bottom of this page in 2.4, explaining how OpenerDirector uses the handlers to open URLs: http://docs.python.org/lib/opener-director-objects.html Looking at the top-level page, I guess an introduction / overview would help? Did you have other stuff in mind too? -- Comment By: Chris Withers (fresh) Date: 04/17/06 07:19 Message: Logged In: YES user_id=24723 I still feel there could be more. I guess the best course, for me, would be to leave this open but at a really low priority. However, I probably wouldn't scream too much if the issue was closed. -- Comment By: John J Lee (jjlee) Date: 04/15/06 11:49 Message: Logged In: YES user_id=261020 They are here: http://docs.python.org/lib/urllib2-examples.html -- Comment By: Chris Withers (fresh) Date: 04/15/06 11:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. -- Comment By: John J Lee (jjlee) Date: 04/15/06 10:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. -- Comment By: Chris Withers (fresh) Date: 06/01/04 01:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... -- Comment By: Martin v. Löwis (loewis) Date: 05/31/04 14:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-ar
[ python-Bugs-1487105 ] 2.5 rev 45972 fails build on Mac-Intel
Bugs item #1487105, was opened at 2006-05-12 07:51 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=1487105&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: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5 rev 45972 fails build on Mac-Intel Initial Comment: brain:~/py25 alex$ make gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/ firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/ mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/ pgenmain.o -ldl -o Parser/pgen /usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) /usr/bin/ld: Undefined symbols: __Py_printgrammar __Py_printnonterminals collect2: ld returned 1 exit status make: *** [Parser/pgen] Error 1 brain:~/py25 alex$ This is a MacBook Pro with gcc version 4.0.1 (Apple Computer, Inc. build 5250) -- not sure why there's an "architecture ppc" found somewhere, haven't looked at it in detail yet, but at any rate this breaks the make. Alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
