Frank Maas wrote:
>>> This object does some basic things for generating XML, hence the
>>> content_type. This, again, works fine. Now the problem - if an
>>> unexisting action for this "XML subclass" is requested, the AUTOLOAD
>>> kicks in. The AUTOLOAD sets the content-type back to HTML
>>> ($r->content_type('text/html')) but this is completely ignored...
>
>
> Solved my own problem, but thought sharing would be good... Apparently it
> was not the content_type call that was ignored. What happens is that
> Apache does an add_output_filter_by_type on each call to
> ap_set_content_type (which is the Apache equivalent of $r->content_type).
> Output filters are however never removed... So if you have (like I did)
> an output filter for a specific type then this happens:
>
> $r->content_type('my/type'); # content_type set AND output filter added
> $r->content_type('text/html'); # content_type changed, output filter
> REMAINS
>
> I don't know if this behaviour is as one would expect and it certainly is
> not a discussion for this list (as it is standard Apache behaviour) but
> worth to know...
yes, good to know. and I saw that when I looked at the code this morning.
but the thing about output filters is they should do something like
return DECLINED unless $r->content_type =~ m/something_I_can_handle/;
so your xml filter should decline (or better, remove itself) from the filter
chain if it's not xml you're being asked to process.
--Geoff
