httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <>
Subject RE: [PATCH] AddOutputFiltersbyType (revised)
Date Tue, 19 Mar 2002 14:40:39 GMT
> From: On Behalf Of Jeff Trawick
> Sent: 19 March 2002 15:14

> "Bill Stoddard" <> 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
>> 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 |


View raw message