© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
I'll try to explain the difference.
First of all: there seems to be no (important) difference in how WSGI and non-WSGI apps are handled (which becomes obvious, if you think of the deploy.ini setup, which does not end with exceptions)
Both, the deploy.ini setup and debug.ini setup call the Zope publisher differently.
deploy.ini: zope.publisher.
debug.ini: zope.publisher.
So, what happens in publish then? I pasted the relevant piece here:
http://
As you can see, after the publication handles the exception (i.e. finds a view for it, sets status code, etc.) in one case (if handle_errors is False) the exception is reraised while in the other case it is not (line 18).
In all cases a view is found and the status set correctly (for Unauthorized at least), but in the debug case the next element in the pipeline (the debugger middleware) takes over afterwards and does not post back the already finished response, but does its debugger stuff.
In the regular-mode instead the exception (turned into HTML) is returned to the browser. In both cases the exception is turned into HTML but only in regular use (handle_
So much for a first analysis.
Where can we hook into it now?
The debugger middleware might be too late in processing. It could check, whether the exception it gets is an Unauthorized, but it would not get the already finished response object, etc. It sounds very crude to me to handle things on this level.
One could instead check, whether the publisher itself could handle exceptions smarter: I'd expect from it to only reraise exceptions in case of 'Internal Server Error'. For this one had to modify the publish function and lots of side effects may arise. At least it would be nice if one could tell the publisher, which exceptions to reraise: none, all or only important ones (internal server errors). This looks like the right location for me to fix.
One could also think of a workaround in the Grok publisher: it should be able to catch the most Unauthorized exceptions and could turn them into an exception view (what the publisher normally does). This sounds also much like a workaround with unwanted side effects.
I tend to opt for fixing this in zope.publisher.
But well, maybe someone has got an idea?