I've been getting a puzzling error. It's not reliably reproduceable. It occurs perhaps one time in four when I'm using Opera. At first, it appeared only to be related to Opera, but now I'm getting the same error in netscape. I can just hit refresh and it works again. There's no sign of anything like ConflictErrors or the like on the console. Has anyone seen this before? What could it be? < snip > File /usr/local/Zope/lib/python/DocumentTemplate/DT_Let.py, line 146, in render (Object: rootpath="absolute_url()") File /usr/local/Zope/lib/python/DocumentTemplate/DT_Util.py, line 334, in eval (Object: absolute_url()) (Info: absolute_url) File <string>, line 0, in ? File /usr/local/Zope/lib/python/OFS/Traversable.py, line 119, in absolute_url (Object: Traversable) KeyError: SERVER_URL Cheers, seb
seb bacon wrote:
I've been getting a puzzling error. It's not reliably reproduceable. It occurs perhaps one time in four when I'm using Opera. At first, it appeared only to be related to Opera, but now I'm getting the same error in netscape. I can just hit refresh and it works again. There's no sign of anything like ConflictErrors or the like on the console.
Has anyone seen this before? What could it be?
< snip >
File /usr/local/Zope/lib/python/DocumentTemplate/DT_Let.py, line 146, in render (Object: rootpath="absolute_url()") File /usr/local/Zope/lib/python/DocumentTemplate/DT_Util.py, line 334, in eval (Object: absolute_url()) (Info: absolute_url) File <string>, line 0, in ? File /usr/local/Zope/lib/python/OFS/Traversable.py, line 119, in absolute_url (Object: Traversable) KeyError: SERVER_URL
Cheers,
seb
I have seen a similar traceback which was due to a bug in CopyPaste.py, to which I have submitted a patch. It had to do with a lack of an acquisition wrapper at an inopportune time. It looks as though absolute_url() is being called without a proper wrapper around the object it is begin called for. What object is it begin called for? -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
Casey Duncan wrote:
seb bacon wrote:
I've been getting a puzzling error. It's not reliably reproduceable. It occurs perhaps one time in four when I'm using Opera. At first, it appeared only to be related to Opera, but now I'm getting the same error in netscape. I can just hit refresh and it works again. There's no sign of anything like ConflictErrors or the like on the console.
Has anyone seen this before? What could it be?
< snip >
File /usr/local/Zope/lib/python/DocumentTemplate/DT_Let.py, line 146, in render (Object: rootpath="absolute_url()") File /usr/local/Zope/lib/python/DocumentTemplate/DT_Util.py, line 334, in eval (Object: absolute_url()) (Info: absolute_url) File <string>, line 0, in ? File /usr/local/Zope/lib/python/OFS/Traversable.py, line 119, in absolute_url (Object: Traversable) KeyError: SERVER_URL
Cheers,
seb
I have seen a similar traceback which was due to a bug in CopyPaste.py, to which I have submitted a patch. It had to do with a lack of an acquisition wrapper at an inopportune time. It looks as though absolute_url() is being called without a proper wrapper around the object it is begin called for.
Looks to me like absolute_url() is being called when absolute_url(1) should be used. -- Steve Alexander
* Steve Alexander <steve@cat-box.net> [010711 07:59]:
KeyError: SERVER_URL
I have seen a similar traceback which was due to a bug in CopyPaste.py, to which I have submitted a patch. It had to do with a lack of an acquisition wrapper at an inopportune time. It looks as though absolute_url() is being called without a proper wrapper around the object it is begin called for.
Looks to me like absolute_url() is being called when absolute_url(1) should be used.
I didn't know about the absolute_url(relative=1) switch. Do virtually hosted envirnoments not have a SERVER_URL variable? However, I don't think this is the problem. (1) I'm not in a virtual hosting scenario (2) it happens at fairly random intervals *on the same page*. I can be working on a page, then reload it, and I get the KeyError. Then I can reload it again and the error goes. Then I go back to it, reload it again, and the error appears. Reload it again and the error remains. Reload it again and it disappears again... You get the idea. This makes it very difficult to debug. I left my computer on overnight, without changing any app settings, and haven't seen the error yet today. My feeling is that Casey's right. It's happening on a CMF object to which I've added BeforeTraverse hooks, which could possibly have something to do with it. However, I've actually seen this problem before, about a year ago, with a completely unrelated ZClass-based objects. I remember then noticing that the error occured more often with Netscape and Opera than IE. Of course, that theory is utter nonsense seeing as HTTP is a connectionless protocol and the headers each browser sends are effectively the same. However, in the absence of a reproduceable error, I have to clutch at straws ;-) seb
OK, I've found out some more stuff about the problem. Of course, it wasn't really random. The culprit is a linked stylesheet. Every time I alter the sheet in some way, I get the SERVER_URL KeyError. I can't really see why this should be happening, though. The absolute_url() in question is in the main body of the document, not the stylesheet. Is perhaps the acquisition wrapper not getting applied to the document until after the linked objects are also downloaded, or something strange like that? I haven't the time time to pursue this right now, but I'll attempt to make a simple, reproduceable example and submit it to the Tracker. But just in case I get time to debug it, where might I start? I'm not very familiar with the Traversal / Publishing stuff. seb * seb bacon <seb@jamkit.com> [010711 10:04]:
* Steve Alexander <steve@cat-box.net> [010711 07:59]:
KeyError: SERVER_URL
I have seen a similar traceback which was due to a bug in CopyPaste.py, to which I have submitted a patch. It had to do with a lack of an acquisition wrapper at an inopportune time. It looks as though absolute_url() is being called without a proper wrapper around the object it is begin called for.
Looks to me like absolute_url() is being called when absolute_url(1) should be used.
I didn't know about the absolute_url(relative=1) switch. Do virtually hosted envirnoments not have a SERVER_URL variable?
However, I don't think this is the problem.
(1) I'm not in a virtual hosting scenario (2) it happens at fairly random intervals *on the same page*.
seb bacon wrote:
OK, I've found out some more stuff about the problem. Of course, it wasn't really random. The culprit is a linked stylesheet. Every time I alter the sheet in some way, I get the SERVER_URL KeyError.
Good, at least we know *when* it happens.
I can't really see why this should be happening, though. The absolute_url() in question is in the main body of the document, not the stylesheet.
Can we see the code for your page? What is the stylesheet, a DTML obj, ZStyleSheet, etc?
Is perhaps the acquisition wrapper not getting applied to the document until after the linked objects are also downloaded, or something strange like that?
No, that is client-side stuff.
I haven't the time time to pursue this right now, but I'll attempt to make a simple, reproduceable example and submit it to the Tracker. But just in case I get time to debug it, where might I start? I'm not very familiar with the Traversal / Publishing stuff.
I'm happy to help if I can.
seb
-- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
<snip stuff about SERVER_URL KeyError> * Casey Duncan <cduncan@kaivo.com> [010711 16:22]:
I haven't the time time to pursue this right now, but I'll attempt to make a simple, reproduceable example and submit it to the Tracker. But just in case I get time to debug it, where might I start? I'm not very familiar with the Traversal / Publishing stuff.
I'm happy to help if I can.
Thanks for the offer. I'll need to take time to assemble something that isn't our entire framework for you to have a look at. Hopefully by the end of the week... cheers, seb
seb bacon wrote:
* Steve Alexander <steve@cat-box.net> [010711 07:59]:
KeyError: SERVER_URL
I have seen a similar traceback which was due to a bug in CopyPaste.py, to which I have submitted a patch. It had to do with a lack of an acquisition wrapper at an inopportune time. It looks as though absolute_url() is being called without a proper wrapper around the object it is begin called for.
Looks to me like absolute_url() is being called when absolute_url(1) should be used.
I didn't know about the absolute_url(relative=1) switch. Do virtually hosted envirnoments not have a SERVER_URL variable?
This actually points to a lack of an acquireable REQUEST object. If you look at the code in absolute_url, it tries to acquire REQUEST and if it can't, it sets it to {}. Then when it does a REQUEST['SERVER_URL'] later on it gets a KeyError. I personally think this code is very brittle, but it does work 99.99% of the time.
However, I don't think this is the problem.
(1) I'm not in a virtual hosting scenario (2) it happens at fairly random intervals *on the same page*.
This is very weird. I would expect it to act consistently. I hate that!
I can be working on a page, then reload it, and I get the KeyError. Then I can reload it again and the error goes. Then I go back to it, reload it again, and the error appears. Reload it again and the error remains. Reload it again and it disappears again... You get the idea.
Is it truely random or an every-other reload sort of regularity? I have a feeling you'll pick the former.
This makes it very difficult to debug. I left my computer on overnight, without changing any app settings, and haven't seen the error yet today.
My feeling is that Casey's right. It's happening on a CMF object to which I've added BeforeTraverse hooks, which could possibly have something to do with it.
Can you experiment with removing/changing these hooks? Can you post the code for your object?
However, I've actually seen this problem before, about a year ago, with a completely unrelated ZClass-based objects. I remember then noticing that the error occured more often with Netscape and Opera than IE. Of course, that theory is utter nonsense seeing as HTTP is a connectionless protocol and the headers each browser sends are effectively the same. However, in the absence of a reproduceable error, I have to clutch at straws ;-)
seb
The browser differences may point to caching differences that make it seem as though it is working. Any DCians have any insights? -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
participants (3)
-
Casey Duncan -
seb bacon -
Steve Alexander