Re: [Zope] standard_error_message woes!
--- The Doctor What <docwhat@gerf.org> wrote:
Gaaah! I'm totally miffed/pissed/confused/sad about this.
I have Zope 2.2.4, and if I go to: http://docwhat.gerf.org:9673/fish (an non-existant object) I get the HTTPResponse.py _error_html() function as called by notFoundError().
Now, if I go to: http://zope.org/fish
I get a nice fully customized error page, which includes where I *might* have ment to go....
What's going on!
I know what you mean. I'm no zopista but I think the problem has to do with the standard error methods not being tied in directly to the object database. There are two files: /lib/python/ZPublisher/HTTPResponse.py /lib/python/OFS/Application.py that contain error pages hard coded in. you get the HTTPResponse.py code for errors like: 403: 'Forbidden', 404: 'Not Found', 405: 'Method Not Allowed', stuff like that. This error code is not parsed like normal dtml and so you can't simply replace it with: """<dtml-var standard_error_message>""" I think this is because these are standard error codes that have to do with the web server and they must work even if the object database doesn't. There must be a more detailed reason why these errors aren't connected to the db, but someone else will have to answer that one. :) jason __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
I think this is because these are standard error codes that have to do with the web server and they must work even if the object database doesn't.
There must be a more detailed reason why these errors aren't connected to the db, but someone else will have to answer that one. :)
This keeps on coming up. It's because certain errors aren't processed as you would expect. For example, try putting a space in a URL going to a Zope server. You get a very horrible error, probably from Medusa... yurch! What you're experiencing is something similar. Most errors do go to the nearest standard_error_message, but there are a load (security being the most notable ones) of errors that just return the hard coded error message, which isn't very nice :-( There was talk of fixing this a while back but nothing happened... Chris PS: almost related, have you noticed how there's no way you can prevent Zope (other than hacking the source) from tacking the error message on the end of the HTML stream, even in production mode? Not only does this produce badly formed HTML, but it gives out way more information that it should to someone potentially looking to hack your site...
Hi Chris, Chris Withers wrote: *snip*
PS: almost related, have you noticed how there's no way you can prevent Zope (other than hacking the source) from tacking the error message on the end of the HTML stream, even in production mode? Not only does this produce badly formed HTML, but it gives out way more information that it should to someone potentially looking to hack your site...
Where was that? I got the position in the source some time... May be we can patch it here and there to get what we all want ;-) And then put it in the collector (which currently lacks an upload facility for patches). This means including the error pages for 40x. I'm also a fan of localisated error messages as well as wap-alized ones ;) In the meantime, have a merry x-mas :-) Regards Tino PS: Chris, will you be in amsterdam?
Tino Wildenhain wrote:
facility for patches). This means including the error pages for 40x. I'm also a fan of localisated error messages as well as wap-alized ones ;)
Hmm... well, this seems like a good Fishbowl project for me. Basically, that code shouldn't be tacked on the end, the error message should be generated by the standard_error_message entirely and not at all dependent on whether or not Zope is running in Debug mode. It's not a big change (maybe 1hrs work?) but, like you, I can't remember where the code lives. Almost related, how about in the same project changing the hard coded errors for security (and anything else like that) so that they use the nearest standard_error_message up the tree? Can't be more than a coupla person-days work... maybe DC has some resource they could spare for this? I would give it a go, but Squishdot seems quite buggy right now and I'd really like to fix it ;-)
PS: Chris, will you be in amsterdam?
Sorry, can't make it :-S cheers, good luck to all for the new year, Chris
* Jason Byron (jason_zope@yahoo.com) [001223 01:04]:
There are two files: /lib/python/ZPublisher/HTTPResponse.py /lib/python/OFS/Application.py
that contain error pages hard coded in.
you get the HTTPResponse.py code for errors like:
403: 'Forbidden', 404: 'Not Found', 405: 'Method Not Allowed',
stuff like that.
This error code is not parsed like normal dtml and so you can't simply replace it with:
"""<dtml-var standard_error_message>"""
I think this is because these are standard error codes that have to do with the web server and they must work even if the object database doesn't.
There must be a more detailed reason why these errors aren't connected to the db, but someone else will have to answer that one. :)
Well I'm very tempted to start mucking in and letting it call an 'external' python method of some sort. At the very least, I'd like the page to be able to look up a list of 'words' and redirect to a webpage if it matches.... Like: http://site.org/fish It finds the keyword fish, and sees there is a legit URL: http://site.org/software/beta/fish And redirects it. But that'd need t ZCatalog at least. Grrrr..... Ciao! -- Chemist who falls in acid is absorbed in work. The Doctor What: Second Baseman http://docwhat.gerf.org/ docwhat@gerf.org KF6VNC
Like: http://site.org/fish
It finds the keyword fish, and sees there is a legit URL: http://site.org/software/beta/fish
And redirects it.
But that'd need t ZCatalog at least.
And probably the PathHandler product to do what you want ;-) cheers, Chris
participants (4)
-
Chris Withers -
Jason Byron -
The Doctor What -
Tino Wildenhain