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 > >