So I propose the following documentation patch many people may not grasp that they need to look into the sources to find out that their filter will always return HTTP-Status OK to their clients although they return SERVER_ERROR ;-)
Tom Geoffrey Young wrote: > > Tom Schindl wrote: > >>Hi, >> >>solved it myself $f->r->status() how stupid I haven't seen this before, >>works like a charme but one more question, what is a filter supposed to >>return on ERROR why does one have to set the status one self and return >>Apache2::Const::SERVER_ERROR from the filter handller isn't setting the >>request-status automatically? E.g. if there's an untrapped error. > > > this is a bug in the filter implementation that someone just needs to get > around to fixing. grep for BAD_REQUEST in modperl_filter.c for the details. > > --Geoff > >
Index: user/handlers/filters.pod =================================================================== --- user/handlers/filters.pod (Revision 387929) +++ user/handlers/filters.pod (Arbeitskopie) @@ -214,8 +214,14 @@ will see that much more difficult things are possible, even though a more elaborated code will be needed. +=head2 Filters and Status codes +The current filter implementation has the disadvantage that the value +returned by your filter-handler is not propagated back to apache. At +the moment the only way to pass another request status to the client +besides OK is to set the status directly like the following: + $f->r->status( Apache::Const::SERVER_ERROR )
signature.asc
Description: OpenPGP digital signature
