[issue826897] Proto 2 pickle vs dict subclass
Andres Riancho added the comment: Well, closing this as wont-fix is far from ideal. +4 years have past from the last activity in this issue but people are still being hit by this issue. In my case I'm not creating any special sub-class, I just use one of Python's built-in libs: ```python import cPickle import Cookie c = Cookie.SimpleCookie() c['abc'] = 'def' unpickled_highest = cPickle.loads(cPickle.dumps(c, cPickle.HIGHEST_PROTOCOL)) unpickled_default = cPickle.loads(cPickle.dumps(c)) print c['abc'].value, c['abc'].value print unpickled_default['abc'].value, unpickled_default['abc'].value print unpickled_highest['abc'].value, unpickled_highest['abc'].value assert unpickled_default['abc'].value == c['abc'].value assert unpickled_highest['abc'].value == c['abc'].value ``` I know there is a work-around (subclass SimpleCookie, override methods, etc.) but it's still going to be something that others will have to implement on their own, they are going to spend time debugging the issue until they reach this bug report, etc. Batteries included should focus on cutting down development time, and this issue increases dev time by introducing strange/hidden limitations to pickle. Is there any plan to actually fix this in the long term? -- nosy: +Andres.Riancho ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue826897 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue826897] Proto 2 pickle vs dict subclass
Andres Riancho added the comment: Django's issue [0] shows the ugly code people write to work around this python bug. [0] https://code.djangoproject.com/ticket/15863 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue826897 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue826897] Proto 2 pickle vs dict subclass
Changes by Andres Riancho andres.rian...@gmail.com: -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue826897 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue826897] Proto 2 pickle vs dict subclass
Changes by Andres Riancho andres.rian...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue826897 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue826897] Proto 2 pickle vs dict subclass
Andres Riancho added the comment: FYI, I'm using Python 2.7.6 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue826897 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14881] multiprocessing.dummy craches when self._parent._children does not exist
Andres Riancho added the comment: Is this a duplicate for http://bugs.python.org/issue10015 #10015 ? -- nosy: +Andres.Riancho ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14881 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17836] multiprocessing exceptions with useful traceback
New submission from Andres Riancho: In pool.py, the worker function reads as follows: http://svn.python.org/view/python/trunk/Lib/multiprocessing/pool.py?view=markup 68 job, i, func, args, kwds = task 69 try: 70 result = (True, func(*args, **kwds)) 71 except Exception, e: 72 result = (False, e) ... 488 if self._success: 489 return self._value 490 else: 491 raise self._value If an exception is raised in the function you sent to the pool, the exception you get has raise self._value as the last line; which is correct but useless for debugging. mp_exception_bug.py reproduces this error. This is the output: Traceback (most recent call last): File mp_exception_bug.py, line 8, in module print p.map(f, [1,2,3]) File /usr/lib/python2.7/multiprocessing/pool.py, line 227, in map return self.map_async(func, iterable, chunksize).get() File /usr/lib/python2.7/multiprocessing/pool.py, line 528, in get raise self._value NameError: global name 'y' is not defined As you can imagine, NameError: global name 'y' is not defined is not enough in complex projects. If we apply some changes to the pool.py we could get something similar to this: Traceback (most recent call last): File /usr/lib/python2.7/multiprocessing/pool.py, line 98, in worker result = (True, func(*args, **kwds)) File /usr/lib/python2.7/multiprocessing/pool.py, line 67, in mapstar return map(*args) File mp_exception_bug.py, line 4, in f return x*y NameError: global name 'y' is not defined Traceback (most recent call last): File mp_exception_bug.py, line 8, in module print p.map(f, [1,2,3]) File /usr/lib/python2.7/multiprocessing/pool.py, line 231, in map return self.map_async(func, iterable, chunksize).get() File /usr/lib/python2.7/multiprocessing/pool.py, line 535, in get raise self._value[0] NameError: global name 'y' is not defined The patch is simple but ugly: import sys import traceback 72c100,102 result = (False, e) --- exc_info = sys.exc_info() tb_string = traceback.format_exc(exc_info[2]) result = (False, (e, tb_string)) 491c532,535 raise self._value --- # Do something with the exception here, the simplest (but ugliest) # thing to do is to simply print it to the console print self._value[1] raise self._value[0] Note that I tried to replace the raise self._value[0] with a raise with three parameters, being the last one the traceback we get using exc_info = sys.exc_info() but sadly it is not possible to pickle tracebacks. I understand that printing is not the best thing to do here, but I wanted to get this discussion started and come to a real solution. Thanks -- components: Library (Lib) files: mp_exception_bug.py messages: 187751 nosy: Andres.Riancho priority: normal severity: normal status: open title: multiprocessing exceptions with useful traceback versions: Python 3.5 Added file: http://bugs.python.org/file30009/mp_exception_bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17836 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11280] urllib2 http_error_302 calls undefined getheaders method
Andres Riancho andres.rian...@gmail.com added the comment:
Please take a deeper look. I think you're trusting the old code more than my
bug report. Some things to keep in mind:
* The headers parameter is a dict. It will never have a getheaders method
* The If you search the whole urllib2.py file, you won't find instances of
headers.getheaders(), you'll find headers.get() , as expected when using a dict.
Also, the call chain to this method is:
* def error(self, proto, *args)
* meth_name = 'http_error_%s' % proto
* args = (dict, proto, meth_name) + args
* return self._call_chain(*args)
* Where args comes from:
error('http', request, response, code, msg, hdrs)
* And the hdrs variable is set here:
code, msg, hdrs = response.code, response.msg, response.info()
* And as you know, the response object returns a dict when info() is called.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11280
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11280] urllib2 http_error_302 calls undefined getheaders method
Andres Riancho andres.rian...@gmail.com added the comment:
One more comment to be added. Please take a look at the following [0] w3af bug
report. The interesting part starts at [ Sun Nov 28 01:25:47 2010 - debug ]
Traceback (most recent call last):.
In there you'll find that my w3af code had a section of urllib2's code in
logHandler.py (self.original_http_error_302(req, fp, code, msg, headers)) and
that the error is very clear (to me at least):
[ Sun Nov 28 01:25:47 2010 - debug ] newurl = headers.getheaders('location')[0]
[ Sun Nov 28 01:25:47 2010 - debug ] AttributeError?: 'dict' object has no
attribute 'getheaders'
[0] https://sourceforge.net/apps/trac/w3af/ticket/160511
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11280
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11280] urllib2 http_error_302 calls undefined getheaders method
Andres Riancho andres.rian...@gmail.com added the comment: Yes, the traceback was in my code because as I stated before: my w3af code had a section of urllib2's code in logHandler.py in other words, I copy+pasted a section of urllib2 into my code. Can't provide a test case now, sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7920] urllib2.HTTPRedirectHandler incorrect redirect
Andres Riancho andresrian...@users.sourceforge.net added the comment:
The problem is still there in 2.7:
urlparts = urlparse.urlparse('C:\\boot.ini')
urlparts
('c', '', '\\boot.ini', '', '', '')
if not urlparts.path:
... urlparts = list(urlparts)
... urlparts[2] = /
...
urlparts
('c', '', '\\boot.ini', '', '', '')
newurl = urlparse.urlunparse(urlparts)
newurl
'c:\\boot.ini'
newurl = urlparse.urljoin( 'http://host.tld/spam/eggs.py', newurl)
newurl
'c:\\boot.ini'
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7920
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7920] urllib2.HTTPRedirectHandler incorrect redirect
New submission from Andres Riancho andresrian...@users.sourceforge.net:
Buggy code:
if 'location' in headers:
newurl = headers.getheaders('location')[0]
elif 'uri' in headers:
newurl = headers.getheaders('uri')[0]
else:
return
newurl = urlparse.urljoin(req.get_full_url(), newurl)
You might end up being redirected to some strange location if for some reason
the value of location is C:\boot.ini, and you urlparse.urljoin the current
URL with that one, you end up with C:\boot.ini . When the urllib2 library opens
that, it will open a local file. What I did to fix it, is to verify that the
protocol of the newurl is http or https.
correct_protocol = newurl.startswith('http://') or
newurl.startswith('https://')
if not correct_protocol:
return
The fix should be applied just below the dangerous urlparse.urljoin.
--
components: Library (Lib)
messages: 99292
nosy: andresriancho
severity: normal
status: open
title: urllib2.HTTPRedirectHandler incorrect redirect
versions: Python 2.5, Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7920
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1028088] Cookies without values are silently ignored (by design?)
Andres Riancho [EMAIL PROTECTED] added the comment: - Problem: The secure flag of cookies is ignored by the load method. - Why is it related to this issue? Because the secure flag is a name without a value: pie=good; other=thing; secure - Why is it bad? Because the RFC says that we should parse it. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1028088 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1028088] Cookies without values are silently ignored (by design?)
Andres Riancho [EMAIL PROTECTED] added the comment: My problem, and the problem if the original bug reporter (sirilyan) is that the load method ignores names that don't have values. Quoting the original bug report: import Cookie q = Cookie.SimpleCookie(pie=good; broken; other=thing) q SimpleCookie: other='thing' pie='good' The original bug report suggested raising a warning or something. I don't like that idea too much. What I would like to see is the secure cookie parameter, which BY RFC has no value, be parsed as expected. Right now is you .load() a cookie that looks like this: a=b; secure and then you want to write that cookie back, you loose the secure parameter! [EMAIL PROTECTED]:~$ python Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type help, copyright, credits or license for more information. import Cookie C = Cookie.SimpleCookie() C.load(chips=ahoy; vienna=finger) print C Set-Cookie: chips=ahoy Set-Cookie: vienna=finger C.load(chips=ahoy; vienna=finger; secure) print C Set-Cookie: chips=ahoy Set-Cookie: vienna=finger I'm not sure if I'm being clear enough, please tell me if you need me to rewrite something, or use other examples. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1028088 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1028088] Cookies without values are silently ignored (by design?)
Andres Riancho [EMAIL PROTECTED] added the comment: The RFC I'm talking about is: http://www.ietf.org/rfc/rfc2109.txt ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1028088 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1028088] Cookies without values are silently ignored (by design?)
Andres Riancho [EMAIL PROTECTED] added the comment: Sorry to bother you guys after so much time, but I think that there is at least one bit of the RFC that isn't respected by this name=value thing... If we look at the RFC we'll see this: cookie-av = Comment = value | Domain = value | Max-Age = value | Path = value | Secure | Version = 1*DIGIT As you may have noticed, Secure doesn't have any values. Also, (but out of the RFC) there is a commonly used cookie flag named HttpOnly [0], which would be nice to correctly parse also. Should _CookiePattern be modified to address this issue? [0] http://www.owasp.org/index.php/HTTPOnly -- nosy: +andresriancho ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1028088 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1401] urllib2 302 POST
Andres Riancho added the comment: As I said in my original bug report, if you don't remove the content-length header or add the data, you are sending an invalid request: START Request= GET http://f00/1.php HTTP/1.1 Content-length: 63 Accept-encoding: identity Accept: */* User-agent: w3af.sourceforge.net Host: f00 Content-type: application/x-www-form-urlencoded END REQUEST === I opened this bug report because this is a bug, not because i'm a RFC purist. I I have time, I'll test the urllib2 patch I coded yesterday and submit it for revision. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1401 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1401] urllib2 302 POST
Andres Riancho added the comment: As mentioned in the RFC, and quoted by orsenthil, however, most existing user agent implementations treat 302 as if it were a 303 response, which is true for urllib2.py too ( see line 585 ): http_error_301 = http_error_303 = http_error_307 = http_error_302 Which means: all redirections are treated the same way. So, if we want to strictly respect the RFC, we should implement 4 different methods: - http_error_301 - http_error_303 - http_error_307 - http_error_302 But urllib2 is implementing the RFC the easy way, this is: threat all redirections the same, threat them as 303. 303 redirections perform a GET on the URI, which urllib2 does here: return Request(newurl, headers=req.headers, origin_req_host=req.get_origin_req_host(), unverifiable=True) These line does not clone the old request completely, it creates a GET request. If we create a GET request (handling 302 as 303) we should remove the content length header! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1401 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1401] urllib2 302 POST
Andres Riancho added the comment: According to the RFC: If urllib2 gets a 302 in response to a request, it MUST send the *same* request to the URI specified in the Location header, without modifying the method, headers, or any data (urllib2 is not RFC compliant here) In urllib2, a 301 and a 307 message should be handled just like a 302. If urllib2 gets a 303 in response to a request, it MUST send a GET request to the URI specified in the Location header (urllib2 is half RFC compliant here, this only works if the original request WASN'T a POST request) I will code a complete patch to make urllib2 work as RFC Compliant as possible. Whenever it's ready i'll send it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1401 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1401] urllib 302 POST
New submission from Andres Riancho:
There is an error in urllib2 when doing a POST request to a URI that
responds with a 302 redirection. The problem is in urllib2.py:536, where
the HTTPRedirectHandler creates the new Request based on the original one:
newurl = newurl.replace(' ', '%20')
return Request(newurl,
headers=req.headers,
origin_req_host=req.get_origin_req_host(),
unverifiable=True)
The issue is that when it creates the new request, it uses the old
headers (which contain a content-length header, remember that we
originally sent a POST!) but doesn't use the same post-data from the
original request (in fact it doesn't use any post-data). So, when the
new request is sent, urllib2 sends something like:
START Request=
GET http://f00/1.php HTTP/1.1
Content-length: 63
Accept-encoding: identity
Accept: */*
User-agent: w3af.sourceforge.net
Host: f00
Content-type: application/x-www-form-urlencoded
END REQUEST ===
The server waits some time for the post-data that is advertised in
Content-length: 63 but it never arrives, so the connection is closed
and urllib2 timeouts.
There are two different solutions to this issue, implementing one is
enough to solve it:
1) when creating the new request, remove the content length header
2) when creating the new request, add the post-data of the old request
I think that the solution 1) is the most RFC-compliant solution. I coded
a small patch for urllib2.py of python2.5 that solves this issue, the
patch simply adds a line that removes the cl header:
newurl = newurl.replace(' ', '%20')
req.headers.pop('content-length')
return Request(newurl,
headers=req.headers,
origin_req_host=req.get_origin_req_host(),
unverifiable=True)
--
components: None
messages: 57223
nosy: andresriancho
severity: minor
status: open
title: urllib 302 POST
type: behavior
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1401
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1401] urllib2 302 POST
Changes by Andres Riancho: -- title: urllib 302 POST - urllib2 302 POST __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1401 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1217] infinite loop in re module
Andres Riancho added the comment: Have you tested it ? Is the re.findall() finishing it's work ? I left it working for 5 minutes or more, and got no response. Cheers, __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1217 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1217] infinite loop in re module
Andres Riancho added the comment: I think this should be reopened. The findall call is running for 3 hours now. I think that it's a clear case of an infinite loop. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1217 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
