httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sumeet Singh <sumeet.si...@openwave.com>
Subject Re: Proposal: AP_FTYPE_PREPROCESS
Date Tue, 27 Apr 2004 00:06:39 GMT
Paul Querna wrote:

>On Sun, 2004-04-25 at 19:25, Nick Kew wrote:
>  
>
>>Rather than use hacks like AP_FTYPE_RESOURCE-1, would it not be
>>better to introduce a new output filter type AP_FTYPE_PREPROCESS
>>below RESOURCE for this kind of application?
>>    
>>
>
>Originally I didn't think this was good; rather that ordering of filters
>should be done by the user/coder.(ie add them in the order you want
>them).  
>
>After talking to niq on IRC, i realized this is contrary to how filters
>already operate (why even have connection type filters then? why not
>have the user apply them in the required order?) 
>
>  
>
Connection filters are different from resource filters because they're 
handled differently. That is, they are bound to the connection and 
therefore are invoked for internal-redirects and error-responses as 
well. Also, an output connection filter does not receive any response - 
headers. All it gets is bucket-brigades.

And protocol filters are different again because you are not allowed to 
modify any content in that stage - so for example if you wrote a 
protocol filter, you can rest assured that the content won't change from 
that point on. You are not assured of the same if your code runs as a 
resource filter. Secondly protocol filters are invoked for 
internal-redirects as well as error responses (resourse and content_type 
fitlers are removed in these cases).

Therefore I think the classification of resource, protocol and 
connection filters has more value and consequence than merely an 
ordering mechanism.

>It makes sense to add another (or even more) types of filters.  This
>allows for cleaner control of the active filters in addition to making
>it easier for everyone involved.
>
>  
>
Apache and httpd core does not treat an AP_FTYPE_RESOURCE any 
differently than an AP_FTYPE_CONTENT_SET filter. Therefore IMHO we might 
as well have just one label for these two (say AP_FTYPE_RESOURCE). 
Modules are already declaring their filters at arbitrary levels 
(mod_cache uses AP_FTYPE_CONTENT_SET -1) and so I don't see any value in 
adding yet another label - unless apache is going to deal with that 
label differently (which is not the case).

-sumeet

>-Paul Querna
>  
>


Mime
View raw message