httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: FW: problem with AddOutputFilterByType directive
Date Wed, 20 Feb 2002 16:32:00 GMT
Justin Erenkrantz wrote:
> On Tue, Feb 19, 2002 at 03:27:04PM -0800, Ryan Bloom wrote:
> 
>>We have a function, ap_pass_brigade(), which is called by every content
>>generator, by definition.  Just put a hook into that function.
>>
> 
> And have that hook called every time data is sent through a
> filter (also output filters call ap_pass_brigade)?  We can only make
> this determination once (when we make this decision we have to be
> sure it is right).  But, there also becomes a point that when we
> positively know the answer, we may be too late to insert arbitrary
> filters.
> 
> I understand why you guys are proposing this solution, but I think
> you're missing my point.  Given our current architecture, we have
> no way of guaranteeing the content-type until most filters have
> been run.

so remove the directive completly.
if it can't be done in ALL cases your going to be surprising
a whole lot of people when suddenly their jsp's dont run a filter
while their servlets do..


> 
> You can't guarantee that the content-type is correct when
> ap_pass_brigade() is called (first time or many times).  You have
> no idea when the content-type will be set.  Any of the filters are
> free to change the content-type as they execute themselves.
> Consider the following case:
> 
> A JSP file that has:
> <% response.setContentType("text/plain") %>
> ...jsp code...
> 
> At what point do we run this hook that checks content-type?  The
> first time ap_pass_brigade() is called, it may have text/html set.
> That may be because mod_mime saw .jsp and said, "Okay, text/html
> for .jsp."  However, the JSP engine (via an Apache 2.0 filter) says,
> "nah, this should be text/plain."  If we base it on the first call to
> ap_pass_brigade(), we add "text/html"'s filters.  If we base it on
> the second call to ap_pass_brigade, you now need "text/plain"'s
> filters.  Say, we have JSP page that produces PHP code (hey, it's
> valid in our architecture), and the PHP script now changes it to
> "application/x-ogg".  So, the content-type is now something else.
> It can arbitrarily flip-flop as ap_pass_brigade() is called and the
> filter tree is walked.
> 
> However, in our current implementation, once we reach the HTTP_HEADER
> state, the content-type must be defined.  How about we do it as a
> filter that ran then?  Possibly even in ap_http_header_filter.  So,
> let's say we do it right before ap_http_header_filter - we're
> *guaranteed* to know content_type by then, right?  Add the filter as
> requested by AddOutputFilterByType.
> 
> Is there a violation of our filter ordering semantics by running this
> filter out-of-order?  We'll be running this filter during HTTP_HEADER.
> Assume you have two filters - one is explicitly at a higher-priority
> to ensure that one is always run *after* another.  Now, say that the
> lower-priority filter is added by this directive (but not the other) -
> we're violating the priorities.  I think that's bad.  So, perhaps, we
> could restrict AddOutputFilterByType to only >= HTTP_HEADER filters.
> If it is less than that, we could produce a config-time error.  That
> seems something that might work.  Thoughts?  I think it may make
> us too restrictive with this directive though.  -- justin
> 
> 




Mime
View raw message