[mod_python] Output filters and 4xx error codes

On 12/16/08 1:20 PM, "Graham Dumpleton" <graham.dumpleton at gmail.com> wrote:
> 
> It would only fall back to that error document if you have multi
> language error documents enabled in Apache configuration. This is not
> generally the default.

OK, my bad there, I had assumed based on the default commented-out config
entries. I confirmed by experimenting with language settings in my browser.

> 
> If it is using these documents, or if you defined your own
> ErrorDocument for that error code, simply add a Location directive for
> the error document URL subset and define another PythonFixupHandler to
> be executed in that context and do what ever it is you want to do.
> 
> In other words, right now your fixup handler only covers /apps and not
> default ones, or those in /cubit, so specify fixup handler for /error
> or /cubit as appropriate.

I am probably mis-interpreting your directions, but this gives me slightly
different behavior, still not running the output filter though, and not
preserving the original error message sent by the client.

Into apps, I added:
 ErrorDocument 403 /cubit-humERROR

Then I defined the second fixuphandler:
<Location /cubit-humERROR>
     PythonPath "sys.path + [ '/usr/local/cubit-mgr.runtime/cgi-bin',
'/usr/local/cubit-mgr.runtime/Cubit']"
     PythonFixupHandler modpython_humproxy::fixuphandler_403
</Location>

And then defined the fixup handler to run the output filter:
def fixuphandler_403(req):
    log("403: status is %s" % req.status)
    # Define the output filter to use for fixing up location
    req.register_output_filter("LOCATIONFIXUP", location_fixup)
    req.add_output_filter("LOCATIONFIXUP")
    return apache.OK

I can confirm that fixuphandler_403() is getting run when the 403 is sent by
the real server. Still, I can confirm from logging that I inserted the
output filter is not running. It also seems that I lost the body of the
original error message from the client. If this is going to work, I'll need
that body as well, and not a generic error message body.

Could it be that once placed under control of ErrorDocument, apache won't
use output filters (or at least user-defined ones)?


--andrew