> From: [EMAIL PROTECTED] On Behalf Of Jeff Trawick > Sent: 19 March 2002 15:14
> "Bill Stoddard" <[EMAIL PROTECTED]> writes: > >> Introduces ap_rset_content_type()... This patch is not complete, I have not finished >> reviewing it (or doing the doc), but it should demonstrate Ryan and Sander's >suggestion >> for inserting resource filters based on content type. I am a bit concerned about >some >> crufty code paths inserting the same filter multiple times into the same output >stream. > > What happens if a would-be generator calls ap_rset_content_type() but > ends up declining? We get a bogus filter on the chain, right? Yes, but, the generator shouldn't call ap_rset_content_type() if it isn't sure it is accepting. If it declines, it shouldn't touch content-type. > What hooks are allowed to set r->content_type today? What hooks would > be allowed to call ap_rset_content_type()? > > If something calls this other than a filter or the one hook that is > really going to generate the content then the filter chain isn't > correct. In which case they probably shouldn't be calling ap_rset_content_type() in the first place. > Is there a cheap way to do a check in ap_pass_brigade() to see if the > content-type changed from the last time we checked? Semi cheap. We would need an extra field in request_req: last_content_type (or something like that). ap_pass_brigade checks if last_content_type and content_type are different, if they are, last_content_type is set to content_type and calls ap_add_output_filters_by_type. After that the brigade is passed on. I think we would be better off documenting when you are allowed to call ap_rset_content_type(). > (but I guess ap_pass_brigade() isn't supposed to know this information) I think so too. > Jeff Trawick | [EMAIL PROTECTED] Sander
