httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [PATCH] AddOutputFiltersbyType (revised)
Date Tue, 19 Mar 2002 14:46:11 GMT
> >> 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().

I agree with Sander.  If a module sets the content-type, it is saying "I
am going to change this type".  For us to protect against broken modules
is incorrect.

On a note in the original message, adding the same filter twice is okay
to do.  In fact, it is arguably correct.  If I have a filter that
changes my c-t to a type that causes me to filter the data again, then I
had better re-insert the filter.  The biggest problem is going to be
infinite loops in this situation, but I am not sure how to protect
against that.

Ryan



Mime
View raw message