OverflowError execption in web.py #713

Closed
juhasch opened this Issue Apr 6, 2013 · 6 comments

Comments

Projects
None yet
4 participants

juhasch commented Apr 6, 2013

I am using Tornado 2.4.1 and get an OverflowError exception in web.py when trying to load a processing.js sketch using Tornado on Windows 7. I can't reproduce it on Linux.

What happens is that calling

ims_value = self.request.headers.get("If-Modified-Since")

returns

"Fri, 01 Jan 1960 00:00:00 GMT"

This causes an OverflowError exeption in time.mktime:

date_tuple = email.utils.parsedate(ims_value)
time.mktime(date_tuple)

Have you tired to run it in python interactive shell? Here is my result in Interactive Shell (Python2.7.3 on Linux)

import email
import time
date_str="Fri, 01 Jan 1960 00:00:00 GMT"
date_tuple = email.Utils.parsedate(date_str)
time.mktime(date_tuple)
-315648000.0
date_tuple
(1960, 1, 1, 0, 0, 0, 0, 1, -1)

As you see, I did't get any OverflowError, but I noticed that the time is before 1970 so that seconds is less than zero...
And, it should be email.Utils rahter than email.utils, isn't it ??
And, I dont't think it is an error related with web.py, for email and time are standand module in python yet...So I did't try your code in web.py...

Best wishes.

Contributor

eguven commented Apr 6, 2013

time docs state that OverflowError is raised from underlying C libraries and

The earliest date for which it can generate a time is platform-dependent.

This seems to be a Windows platform issue.

juhasch commented Apr 6, 2013

I tried the above example in IPython using Windows and Linux.
Windows:

In [5]: time.mktime(date_tuple)
---------------------------------------------------------------------------
OverflowError                             Traceback (most recent call last)
 in ()
----> 1 time.mktime(date_tuple)
OverflowError: mktime argument out of range

Linux (Opensuse 12.2):

In [5]: time.mktime(date_tuple)
Out[5]: -315622800.0

Linux (Raspberry Pi running Archlinux):

In [5]: time.mktime(date_tuple)
Out[5]: -315619200.0

The standard library documentation http://docs.python.org/2/library/time.html says:

  • The epoch is the point where the time starts. On January 1st of that year, at 0 hours, the “time since the epoch” is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0).
  • The functions in this module do not handle dates and times before the epoch or far in the future. The cut-off point in the future is determined by the C library; for Unix, it is typically in 2038.

So as I understand it, time.mktime is not expected to work with dates before 1970 and what happens is undefined. Under Linux it returns different results, depending on architecture, Windows throws an exception.

How should this be handled ?

Contributor

eguven commented Apr 6, 2013

Using datetime instead of time might be a good idea (haven't tested on Win).

import datetime
date_str = 'Fri, 01 Jan 1960 00:00:00 GMT'
fmt = '%a, %d %b %Y %H:%M:%S %Z'
datetime.datetime.strptime(date_str, fmt)

You should close this issue.

juhasch commented Apr 6, 2013

OK, I will close this issue.

Still, I had to patch my local copy of Tornado and IPython notebook (which uses the same time.mktime code) in order to catch the OverflowError exception on Windows.

@juhasch juhasch closed this Apr 6, 2013

Owner

bdarnell commented Apr 6, 2013

Sigh. Processing.js is asking for trouble by using a pre-epoch timestamp in a field that has no reason to ever see a timestamp that predates HTTP, but it's still a valid header and tornado shouldn't blow up if it sees a value far in the past (or future). This code is already using datetimes, so it should probably be rewritten to construct the datetimes without going through a time_t.

@bdarnell bdarnell reopened this Apr 6, 2013

@bdarnell bdarnell closed this in d2457ec Apr 13, 2013

@juhasch juhasch referenced this issue in ipython/ipython Apr 14, 2013

Closed

OverflowError execption in handlers.py #3177

minrk added a commit to minrk/ipython that referenced this issue Apr 15, 2013

@minrk minrk referenced this issue in ipython/ipython Apr 15, 2013

Merged

backport If-Modified-Since fix from tornado #3181

minrk added a commit to ipython/ipython that referenced this issue Apr 24, 2013

Merge pull request #3181 from minrk/ifsince
backport If-Modified-Since fix from tornado

See tornadoweb/tornado#713

closes #3177

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014

Merge pull request #3181 from minrk/ifsince
backport If-Modified-Since fix from tornado

See tornadoweb/tornado#713

closes #3177
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment