[mod_python] Output filters and 4xx error codes

What are you actually trying to change? Response content or response headers?

2008/12/17 Andrew Ryan <andrewr at collab.net>:
> 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
>
>