Tom Schindl wrote: > Hi Geoff, > > Geoffrey Young wrote: > >>Tom Schindl wrote: >> >> >>>This means the when the documentation holds information about situation >>>where one has to use $r->status(), I would propose that in should add >>>the use case of filters. >>> >>>This has nothing TODO with your problem I only wanted to point out that >>>not all cases where setting $r->status manually are documented there. >> >> >>you really should never alter $r->status, as apache uses it for internal >>bookeeping... >> > > > Although that's not on this special topic your do you also think that > setting $r->status() in an output filter is a wrong or is this desired > behaviour?
well, I'm not sure that filters differ from any other handler in this regard, since it all happens before httpd sends the response to the client and before it can enter the error document cycle, which is where this stuff matters. it actually doesn't matter a whole lot, but the last time I checked it fell out like this - if you set $r->status manually and the request fails your error document cycle could get mucked up, resulting in default "a blah error was also encountered" if you use the default error pages. not that it's all that big a deal, but prevailing wisdom through the ages (here and on the httpd lists) has been "don't do that." people question it from time to time and IIRC someone even started to code httpd so that you _could_ do it with impunity. but I'm not sure if that made it in or not. anyway, I'm probably making a bigger deal of this than it really is :) > > See my question a few days ago. Is this a bug? it's a feature :) until someone reworks our filter mechansim to make it right. my pointer was only to the comments in modperl_filter.c, comments I logged maybe 2 years ago when I tried to do the exact same thing :) --Geoff
