Re: FW: problem with AddOutputFilterByType directive
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
FW: problem with AddOutputFilterByType directive
On Mon, Feb 18, 2002 at 09:17:19PM -0800, Ian Holsman wrote: it doesn't do what it is supposed to do ALL the time. for example.. take mod-status. inside the handler it decides what type of content-type the program will return. bad module, fix module. That's bogus. Consider mod_cgi, which can't determine the content type until the first bucket is written. I'm with Ian on this one. *) add a filter (with a priority of -1 FTYPE_CONTENT) which just checks the content-type and adds the other filter if it passes. If we have to do this, then I think our architecture is in poor shape. I don't think a filter is the right place to do this - there is way too much overhead in a filter to do this logic. And, we'd also be adding a filter after we've sent data down the filter chain. (Don't get me wrong, I see your rationale behind this, but if the only way to do this is via another filter, we've got problems.) I could be wrong, but I think the way I did it is the right way to do this given what we have now. Anyone else? Am I wrong? -- justin We have a function, ap_pass_brigade(), which is called by every content generator, by definition. Just put a hook into that function. Ryan
Re: FW: problem with AddOutputFilterByType directive
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. 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
