Jon Delheimer writes:
charset="iso-8859-1"
Shane,
I made the changes you suggested to Image.py.
Here are the results:
... Thursday, 11-May-00 15:53:50 GMT 1900/05/11 15:53:50 GMT -2197699570.0
That explains the exception: 1900 is a bit too far in the past. Seems that Netscape sends such a strange "If-Modified-Since" header. You can try to fix this problem, by removing the "int(...)" in "OFS.Image.py:186" mod_since=int(DateTime(header).timeTime()) ==== > mod_since=DateTime(header).timeTime()
You Rock Dieter, Thanks to everyone for their input! This has solved the nasty Netscape Image problem for now! j john@nurl.net At 09:05 PM 5/23/00 +0200, you wrote:
Jon Delheimer writes:
charset="iso-8859-1"
Shane,
I made the changes you suggested to Image.py.
Here are the results:
... Thursday, 11-May-00 15:53:50 GMT 1900/05/11 15:53:50 GMT -2197699570.0
That explains the exception: 1900 is a bit too far in the past. Seems that Netscape sends such a strange "If-Modified-Since" header.
You can try to fix this problem, by removing the "int(...)" in "OFS.Image.py:186"
mod_since=int(DateTime(header).timeTime())
==== >
mod_since=DateTime(header).timeTime()
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Given Itamar's comments, I have changed his suggestion as follows:
You can try to fix this problem, by removing the "int(...)" in "OFS.Image.py:186"
- mod_since=int(DateTime(header).timeTime())
+ mod_since=long(DateTime(header).timeTime())
I've checked this in for 2.2. Thanks for investigating this guys!
--Brian
Woohoo! :-) Chris
On Wed, May 24, 2000 at 02:19:43PM +0100, Chris Withers wrote:
Given Itamar's comments, I have changed his suggestion as follows:
You can try to fix this problem, by removing the "int(...)" in "OFS.Image.py:186"
- mod_since=int(DateTime(header).timeTime())
+ mod_since=long(DateTime(header).timeTime())
I've checked this in for 2.2. Thanks for investigating this guys!
--Brian
Woohoo! :-)
Chris
I've changed Image.py as suggested in the line above but I was still getting some strange behaviour so I pursued it a little bit further. I encountered the following strange behaviour when using the debugger to step through the code: The image I'm looking for has: Last-Modified: Wed, 15 Mar 2000 19:02:17 GMT Upon executing: ZPublisher.Zope('/path/to/image', d=1) and stepping into the debugger I set: environ['IF_MODIFIED_SINCE'] = 'Wed, 15 Mar 2000 19:02:17 GMT' when I get to lib/python/OFS/Image.py(line 188) I get the following strange results:
OFS/Image.py(188)index_html() -> if last_mod > 0 and last_mod <= mod_since: pdb> print mod_since, last_mod 953146936 953146937 <<<< Something is wrong! mod_since should equal last_mod pdb> print DateTime(header).timeTime() 953146937.0 pdb> print self._p_mtime 953146937.38 pdb> int(953146937.0) 953146937 pdb> print int(DateTime(header).timeTime()) 953146936 <<<< WHAT!? pdb> type( DateTime(header).timeTime() ) <type 'float'> pdb> int(DateTime(header).timeTime()) 953146936 <<<< I still don't believe this. pdb> DateTime(header).timeTime() 953146937.0 pdb> print header Wed, 15 Mar 2000 19:02:17 GMT pdb> long(DateTime(header).timeTime()) 953146936L <<<< long also does it!?
I'm completly baffled by this, how can int/long be interacting with DateTime(header).timeTime() to produce this error? ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com ------------------------------------------------------
In a previous posting about Netscape Image problems I mentioned a weird interaction between int() and DateTime.timeTime(). I can reproduce the error within the python interpreter as follows- Python 1.5.2 (#5, Jan 6 2000, 17:10:24) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
from DateTime import DateTime h = 'Wed, 15 Mar 2000 19:02:17 GMT' t = DateTime( h ) print t 2000/03/15 19:02:17 GMT t.timeTime() 953146937.0 int( t.timeTime() ) 953146936 <<<<< This is wrong int( 953146937.0 ) 953146937
Any ideas on how this can be happening. Stepping through the DateTime module yields the sensible return value of 953146937.0 but somehow int() converts this incorrectly. ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com ------------------------------------------------------
andres@corrada.com wrote:
In a previous posting about Netscape Image problems I mentioned a weird interaction between int() and DateTime.timeTime(). I can reproduce the error within the python interpreter as follows-
Python 1.5.2 (#5, Jan 6 2000, 17:10:24) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
from DateTime import DateTime h = 'Wed, 15 Mar 2000 19:02:17 GMT' t = DateTime( h ) print t 2000/03/15 19:02:17 GMT t.timeTime() 953146937.0 int( t.timeTime() ) 953146936 <<<<< This is wrong int( 953146937.0 ) 953146937
Any ideas on how this can be happening. Stepping through the DateTime module yields the sensible return value of 953146937.0 but somehow int() converts this incorrectly.
Simple: DateTime has been using floating-point calculations. I believe all of that has been corrected, however, with the new DateTime module, available in the public CVS repository. Shane
On Thu, May 25, 2000 at 12:56:48PM -0400, Shane Hathaway wrote:
Simple: DateTime has been using floating-point calculations. I believe all of that has been corrected, however, with the new DateTime module, available in the public CVS repository.
Shane
I don't understand how your answer explains the buggy behaviour. If DateTime.timeTime() returns a float that's okay. Why should a call to it wrapped with int() return the incorrect answer?
t.timeTime() 953146937.0 int( t.timeTime() ) 953146936 int( 953146937.0 ) 953146937
------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com ------------------------------------------------------
On Thu, 25 May 2000 andres@corrada.com wrote:
On Thu, May 25, 2000 at 12:56:48PM -0400, Shane Hathaway wrote:
Simple: DateTime has been using floating-point calculations. I believe all of that has been corrected, however, with the new DateTime module, available in the public CVS repository.
Shane
I don't understand how your answer explains the buggy behaviour. If DateTime.timeTime() returns a float that's okay. Why should a call to it wrapped with int() return the incorrect answer?
t.timeTime() 953146937.0 int( t.timeTime() ) 953146936 int( 953146937.0 ) 953146937
Check this out: Python 1.5.2 (#3, Mar 8 2000, 16:34:52) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
f = 1.999999999999 f
2.0
int(f) 1
This was on one of our Solaris boxes. Apparently, the string representation of a float having the value 1.999999999999 is 2.0, while the int() function takes a different code path and returns 1, correctly. I could be wrong, but I think that's what's biting you. --Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:jeff.hoffman@goingv.com Going Virtual, L.L.C. http://www.goingv.com/
"Jeff K. Hoffman" wrote:
Python 1.5.2 (#3, Mar 8 2000, 16:34:52) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
f = 1.999999999999 f
2.0
int(f) 1
the int() function takes a different code path and returns 1, correctly.
Forgive my ignorance, but in what way is 1 correct here? Surely 2 is the what should be returned?! Chris
On Thu, May 25, 2000 at 06:48:51PM +0100, Chris Withers wrote:
"Jeff K. Hoffman" wrote:
Python 1.5.2 (#3, Mar 8 2000, 16:34:52) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
f = 1.999999999999 f
2.0
int(f) 1
the int() function takes a different code path and returns 1, correctly.
Forgive my ignorance, but in what way is 1 correct here? Surely 2 is the what should be returned?!
From the python int doc string:
print int.__doc__ int(x) -> integer
Convert a string or number to an integer, if possible. A floating point argument will be truncated towards zero. ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com ------------------------------------------------------
andres@corrada.com wrote:
From the python int doc string:
print int.__doc__ int(x) -> integer
Convert a string or number to an integer, if possible. A floating point argument will be truncated towards zero.
I _always_ get bitten by this :( Sorry for my igorance, Chris
On Thu, 25 May 2000, Chris Withers wrote:
"Jeff K. Hoffman" wrote:
Python 1.5.2 (#3, Mar 8 2000, 16:34:52) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
f = 1.999999999999 f
2.0
int(f) 1
the int() function takes a different code path and returns 1, correctly.
Forgive my ignorance, but in what way is 1 correct here? Surely 2 is the what should be returned?!
int() disregards everything after the decimal.
int(1.25) 1 int(1.5) 1 int(1.75) 1 int(1.999999999999) 1 int(2) 2
The problem comes in when you consider that the string representation functions (and thus, print) do not behave in the same way.
print 1.25 1.25 print 1.5 1.5 print 1.75 1.75 print 1.9 1.9 print 1.999 1.999 print 1.99999 1.99999 print 1.9999999 1.9999999 print 1.999999999 1.999999999 print 1.99999999999 1.99999999999 print 1.9999999999999 2.0
Chris
--Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:jeff.hoffman@goingv.com Going Virtual, L.L.C. http://www.goingv.com/
Shane Hathaway wrote:
Simple: DateTime has been using floating-point calculations. I believe all of that has been corrected, however, with the new DateTime module, available in the public CVS repository.
And will be in 2.2? Chris
On Tue, May 23, 2000 at 09:05:55PM +0200, Dieter Maurer wrote:
You can try to fix this problem, by removing the "int(...)" in "OFS.Image.py:186"
mod_since=int(DateTime(header).timeTime())
==== >
mod_since=DateTime(header).timeTime()
Using the %{If-Modified-Since}i directive in the Apache log, we have been able to confirm that Netscape 3.01 and 4.06 on Win32 are sending If-Modified-Since with "16-May-00" type dates. Dieter's solution indeed fixes the problem by removing the Overflow error that they cause when the int() function is called on them. I noticed that Zope 2.1.4 does not have these int() calls in the offending section of lib/python/OFS/Image.py but they are present in 2.1.6. Why were they introduced on the latter version? Can they be removed in future versions? ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com ------------------------------------------------------
andres@corrada.com wrote:
Using the %{If-Modified-Since}i directive in the Apache log, we have been able to confirm that Netscape 3.01 and 4.06 on Win32 are sending If-Modified-Since with "16-May-00" type dates. Dieter's solution indeed fixes the problem by removing the Overflow error that they cause when the int() function is called on them.
I noticed that Zope 2.1.4 does not have these int() calls in the offending section of lib/python/OFS/Image.py but they are present in 2.1.6. Why were they introduced on the latter version? Can they be removed in future versions?
No, they can't - HTTP datetime headers specify time in whole seconds, while the time() function on Unix machines returns time with a floating point time. In order for Zope to work correctly the you have to make timeTime()'s result be a whole number. long() would be fine though, or floor(). -- Itamar S.T. itamar@maxnm.com
participants (7)
-
andres＠corrada.com -
Chris Withers -
Dieter Maurer -
Itamar Shtull-Trauring -
Jeff K. Hoffman -
john＠nurl.net -
Shane Hathaway