|
Graham Dumpleton
graham.dumpleton at gmail.com
Tue Dec 16 16:20:33 EST 2008
2008/12/17 Andrew Ryan <andrewr at collab.net>: > On 12/16/08 12:37 PM, "Graham Dumpleton" <graham.dumpleton at gmail.com> wrote: > >> Post your Apache configuration snippet which shows in what context you >> are setting up your fixup handler, ie., what URL subset. > > <Location /apps> > PythonPath "sys.path + [ '/usr/local/cubit-mgr.runtime/cgi-bin', > '/usr/local/cubit-mgr.runtime/Cubit']" > # Make sure we don't accept gzip, etc. When we filter, we need to > # insure we're working with plaintext. > RequestHeader unset Accept-Encoding > PythonFixupHandler modpython_humproxy > ErrorDocument 502 /cubit/Help/hum_502_page > # Apache 2.2 seems to send a 503 for what 2.0 sent a 502 for (the > # back-end page not being available) > ErrorDocument 503 /cubit/Help/hum_502_page > </Location> > >> >> For error documents, is it falling back to builtin Apache error >> document strings or is ErrorDocument directive actually being set for >> that error type? > > Should be falling back to the built-in error document string > (/error/HTTP_FORBIDDEN.html.var), because 403 ErrorDocument directive is not > set anywhere else in the configuration, in any URL space or at the server > level. 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. 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. Graham > --andrew > > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python >
|