New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms #49787
Comments
The LWPCookieJar can be saved on 64-bit Ubuntu, but not on 32-bit Ubuntu A sample crash is shown below: File "/home/user/xblstatus/LiveConnect.py", line 189, in connect --- The cookie jar and urllib2 integration was done with: self.cookiejar = cookielib.LWPCookieJar()
self.opener =
urllib2.build_opener(urllib2.HTTPCookieProcessor(self.cookiejar))
urllib2.install_opener(self.opener) The code used to save the cookie after accessing the web page was: self.cookiejar.save(self.cookieFile) The cookieFile variable is simply the default location of the cookie |
Shouldn't module time be changed to use a cross-platform implementation that uses a 64 bit time_t-like type? Apparently Perl 6 has made the equivalent change. Admittedly there seems to be no sign of that actually happening. |
The error occurs on time.gmtime(t): even if we use 64 bits time_t type, we have to downcast it to system time_t later, because we would like to call gmtime() function at the end. To workaround gmtime() limitation: we can simply use datetime instead. Attached patch replaces gmtime() by datetime.utcfromtimestamp(), and use its .strftime() method which has no such limitation. |
Oh, my patch is incomplete: time2netscape() has the same issue. |
Victor, I don't see your patch. Did you remove it? |
No, I forgot to upload it... |
While it is unlikely that a purely numeric format such as "%Y-%m-%d |
If datetime.strftime() is not reliable, we should maybe fix it instead of using a workaround? |
On Fri, Feb 18, 2011 at 11:04 AM, STINNER Victor <report@bugs.python.org> wrote:
The real fix would be to rewrite strftime so that it does not call |
New changeset b15f60f9e256 by Victor Stinner in branch '3.1': |
Ok, I rewrote my patch to avoid strftime(). It should now be fixed. FYI datetime.fromtimestamp() converts the timestamp to a double, which has a precision of 53 bits (no precision loss for year < 285,422,890 and so it's enough for year 2038). |
This bug still exists in Python 2.7.3 32-bit on Linux. I wonder if this might be because the patch (posted 2011-02-18) used utcfromtimestamp(). datetime.datetime.utcfromtimestamp(2**32) will fail on 32-bit systems. The bug does NOT exist in Python 2.7.3 32-bit on Windows (64-bit OS). ========================================== $ python -c "import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767)"
2.7.3 (default, Apr 10 2013, 05:46:21)
[GCC 4.6.3]
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/cookielib.py", line 99, in time2isoz
year, mon, mday, hour, min, sec = time.gmtime(t)[:6]
ValueError: timestamp out of range for platform time_t
==========================================
========================================== $ python -c "import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767)"
2.7.3 (default, Aug 3 2012, 17:21:07)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)]
2043-08-11 16:36:07Z
==========================================
========================================== |
For those who are affected by this bug, here's a snippet to monkey-patch cookielib on any Python 2.4 to 2.7. A more complete version of this was attached to my message a moment ago. ========================================== import cookielib
try:
cookielib.time2isoz(2**32)
except ValueError:
from datetime import datetime, timedelta
def time2isoz(t=None):
if t is None:
dt = datetime.now()
else:
dt = datetime.utcfromtimestamp(0) + timedelta(seconds=int(t))
return "%04d-%02d-%02d %02d:%02d:%02dZ"%\
(dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second)
cookielib.time2isoz = time2isoz ========================================== |
Apologies for the necro on this issue, but should this now be fixed in Python3.7? As it appears to still be an issue. Testing on a Raspberry Pi with LibreELEC (32-bit OS): rpi512:~ # python -c "import sys, http.cookiejar; print(sys.version); print(http.cookiejar.time2isoz(2322923767))"
3.7.6 (default, Feb 12 2020, 17:36:39)
[GCC 9.2.0]
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.7/cookiejar.py", line 101, in time2isoz
OverflowError: timestamp out of range for platform time_t This is on a distribution built with latest glibc-2.31. |
Oh, maybe the bug wasn't properly fixed? Can you please try the patch above? diff --git a/Lib/http/cookiejar.py b/Lib/http/cookiejar.py
index 47ed5c3d64..55915cf18a 100644
--- a/Lib/http/cookiejar.py
+++ b/Lib/http/cookiejar.py
@@ -99,7 +99,7 @@ def time2isoz(t=None):
if t is None:
dt = datetime.datetime.utcnow()
else:
- dt = datetime.datetime.utcfromtimestamp(t)
+ dt = datetime.datetime(1970, 1, 1) + datetime.timedelta(seconds=t)
return "%04d-%02d-%02d %02d:%02d:%02dZ" % (
dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second)
For example, copy http/ subdirectory in the current directory, and then patch manually http/cookiejar.py file. |
Hi Victor I can confirm the patch is working on both 32-bit and 64-bit systems running Python3.7.6, with both platforms returning the same result after patching - many thanks! #### UNPATCHED, 32-bit (RPi3+)
LibreELEC (Milhouse.testing): devel-20200213234919-#0213f-g70b69eb (RPi2.arm)
rpi22:~ # python -c "import sys, http.cookiejar; print(sys.version); print(http.cookiejar.time2isoz(2322923767))"
3.7.6 (default, Feb 14 2020, 00:35:22)
[GCC 9.2.0]
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.7/cookiejar.py", line 101, in time2isoz
OverflowError: timestamp out of range for platform time_t #### PATCHED, 32-bit (RPi3+) #### UNPATCHED, 64-bit (x86_64) #### PATCHED, 64-bit (x86_64) |
Just an FYI, this is also broken on 32-bit with Python2.7.16, so possibly it was never fixed originally (rather than being a regression). LibreELEC (Milhouse): devel-20191012235627-#1012-ge416c8b (RPi2.arm)
rpi22:~ # python -c "import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767)"
2.7.16 (default, Sep 29 2019, 04:11:31)
[GCC 9.2.0]
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/cookielib.py", line 99, in time2isoz
ValueError: timestamp out of range for platform time_t |
I'm not a big fan of utcfromtimestamp (as you can see here: https://blog.ganssle.io/articles/2019/11/utcnow.html ), but it seems we do have the same issue in |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: